Skip to content

Add "Read Security Policies" as a permission for custom roles

Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.

Release notes

Problem to solve

Access and permissions to execute scan or pipeline execution policies today depends on read access to the security policy project containing the policy configuration.

We extended a solution to simplify access to necessary configuration during pipeline execution in 17.4:

In GitLab 17.4 and later, you can grant the required read-only access for the CI/CD configuration file specified in a security policy project using the content type. To do so, enable the setting Pipeline execution policies in the general settings of the security policy project. Enabling this setting grants the user who triggered the pipeline access to read the CI/CD configuration file enforced by the pipeline execution policy. This setting does not grant the user access to any other parts of the project where the configuration file is stored.

However, this is not an evergreen solution to access/permissions and enforcement of security policies.

Custom roles/permissions however will more transparently and consistently allow users who should be able to read policies, read underlying configurations and to have policies imposed or applied upon them.

Intended users

User experience goal

Proposal

  1. Users should be able to read the policies to understand what policies are configured/enforced in projects they manage or work within (developers, appsec, compliance, and other roles should be able to view the policies).
  2. When a pipeline is executed in a project, regardless of the user executing the pipeline, policies should be enforced as defined. If a pipeline execution policy or scan execution policy is configured and enforced against a given project and a user has rights to execute a pipeline, the policy jobs should be properly executed as well. This may be more of a resource based permission -- the pipeline itself should be able to read the policy configuration and execute jobs. The user separately had rights to execute a pipeline and may or may not need to view the underlying configuration itself.
  3. Separately, users with rights defined in Add "Manage Security Policies" as a permission ... (#444547) are users bestowed with the role and necessary access/permissions to enforce policies that change behaviors in the target repositories. While this is a separate set of permissions, it is context that these users apply the policies and then users/resources with read access can view/read policy configurations to achieve their tasks.
  4. An additional consideration with SEP/PEP, is that of "what" users/resources should be able to read or access. Proper read access should be supplied to users/resources to ensure policies are applied where expected while users also are only able to read/view what is necessary for their tasks. PEPs can contain the following:
    1. They are defined in the policy.yml which describes the policy.
    2. They contain a config file, e.g. pipeline-execution.yml, which outlines configuration that will override or inject jobs into project pipelines. This may also contain sensitive information at times (like resource paths, variables, or credentials).
    3. They may use includes that reference external files/data used by the configuration, including secrets/credentials or sensitive information.

Further details

Permissions and Security

Documentation

Availability & Testing

Available Tier

Feature Usage Metrics

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

What is the type of buyer?

Is this a cross-stage feature?

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 🤖 GitLab Bot 🤖