Granular Security Permissions

Release notes

Problem to solve

Currently there is no ability to separate out the duties between the engineering security teams in a way that adheres to the Principle of Least Privilege.

Security teams Security teams need to not have write access (Maintainer access) to code repositories. They also need to be able to approve merge requests, view vulnerabilities, and change the status of vulnerabilities.

Engineering teams Engineering teams need to need to have either Developer or Maintainer access to code repositories as appropriate for their role. They need to be able to view vulnerabilities but they should not be permitted to change the status of those vulnerabilities.

Intended users

Proposal

  1. add the following customer permissions to a custom role (built on top of the Reporter role as a base):
    1. Change vulnerability status - admin_*
    2. Approve Merge Requests - admin_*, currently blocked, see comment.
    3. View Security Dashboard - read_*
    4. View Vulnerability Report - read_*, already done
    5. View Dependency List - read_*
  2. All existing Developer users will be migrated to use a new custom role with Developer permissions plus the Change vulnerability status permission. This migration is necessary to avoid a breaking change when implementing requirement 3 below.
  3. We would remove the following permission from the current Developer and Maintainer roles:
    1. Change vulnerability status

Further details

The new customizable roles framework permissions is additive only. Instead of Change vulnerability status permission included as a part of both the Developer and Maintainer roles, users will need to do something like Reporter + Change vulnerability status

Permissions and Security

Documentation

Availability & Testing

Available Tier

  • Ultimate/Gold

Feature Usage Metrics

What does success look like, and how can we measure that?

What is the type of buyer?

GitLab Ultimate

Is this a cross-stage feature?

Yes! ~"group::authentication and authorization" will work closely with groupthreat insights.

~"group::authentication and authorization" will do a walkthrough of our contributor docs, in %16.0 on what the set of changes your team will have to make to add a set of permissions.

What is the competitive advantage or differentiation for this feature?

Links / references

This page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.

Edited by Alana Bellucci