GitLab Gitlab 12.8 Release Kickoff, 15 Jan 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: GitLab 12.8 Kickoff - Manage:Compliance

Description

Apply compliance controls to projects: https://gitlab.com/gitlab-org/gitlab/issues/118671
Configure push rules at the group level: https://gitlab.com/gitlab-org/gitlab/issues/34370
Allow developers to push to projects they create in a group: https://gitlab.com/gitlab-org/gitlab/issues/7583
Credential inventory for group managed accounts: https://gitlab.com/gitlab-org/gitlab/issues/38133
Audit Events: Track changes in MR approval settings: https://gitlab.com/gitlab-org/gitlab/issues/7531
Audit Events: Track user edits by admins: https://gitlab.com/gitlab-org/gitlab/issues/251
Audit Events: Track username changes: https://gitlab.com/gitlab-org/gitlab/issues/7797

Compliance Special Interest Group (SIG): https://gitlab.com/gitlab-compliance-sig

A

Hi everyone, my name- is Matt Gonzalez and I'm. The product manager here at gitlab for the compliance group I'm excited to review the plan for 12-8 today and I hope you'll, find it as exciting as I. Do. One of the big features that we're working on is this concept of applying compliance controls to projects organizations generally operate in in our industry. That's regulated to some degree, whether that's on the data privacy side or even just the the functional process side.

A

Things from sarbanes-oxley to GDP are we'd like to make iterative steps towards helping to solve that pain point by letting you ensure that your projects are compliant from the moment they're created.

A

The idea here is we'd like to implement a feature that allows you to specify what the default settings or enforceable policies could be for your projects in our first iterative step, it'll focus on merge, request, approvals and we'd like to provide evidence, artifacts and visual indicators throughout the process to let you know that those policies have been maintained, we're also looking at bringing push rules to the group level right now. This exists for in self-managed instance, administrators, but there's a gap for com customers.

A

This is still something valuable and provides a lot of control for a good live environment, and so we felt it was important to bring this feature. Parity to calm.

A

A long-standing bug around the creation of projects within a gay lab environment- we're protected branches, are enabled. The idea here is that there are situations where a customer needs a developer, to be able to create a project and push some initial code to that project. What we're attempting to do here in 12-8 is add an optional setting at the group level.

A

That says you know anybody can make a project, but only if you have permission to push to a protected branch can your project then default to protecting the master branch the workflow, for that would be. If this setting is disabled, then nothing changes. The workflows and experience remain the same.

A

If it's enabled, then, when somebody goes to create a new project, if they have the permission or the ability to push your protected branch, they can optionally protect the master branch for this new project in the event that they don't have, that permission then hard to see here potentially, but this would be grayed out or disabled from being selected so that the new projects master branch can be pushed to by the developer or the individual trying to start the project.

A

We're also looking at bringing the credential inventory, we released in twelve six to calm at the group level. So, as you can see from our previous release, we created this inventory of personal access, tokens and SSH keys, which provides a level of visibility and control for now.com group owners and so bringing that feature. Parity from the instance level to the group level is the intent.

A

There's a few audit log improvements slated or planned for 12-8 as well. We have some very ambitious goals and I'm hopeful that we can achieve all of them, of course, but as far as the audit logging is concerned, one of the hierarchy themes is to add a lot more of granularity to the data that we provide an audit events log in this particular case. We're wanting to add changes for the merge request.

A

Approval settings at a minimum, we'd like to be able to show you for auditing purposes when those changings are modified, where those changes modified before a deploy or were they left intact, which, as to the integrity of that process, that's in place.

A

We're also looking at for self managed instance, logs looking at when users were created, blocked deleted that access management component that is currently missing so we'd like to add that granularity there and finally, we're also adding to the audit log changes made to usernames whether an admin makes the change, themself or a user, makes the change we'd like to make sure that those events are captured as part of that Identity and Access Management auditability.

A

So this is the ambitious goal for 12 8 and I'm hopeful. We can attain all of it. As always, your feedback is welcome and we'd love to have you contribute to the vision for compliance. Please see the video description for link to our compliance special interest group, as well as links to these issues where we'd love to hear your feedback thanks for listening.