Feedback Issue: Pipeline Execution Policy

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

• Close this issue

Description

Pipeline execution policies were released in %17.2. This feature supports enforcement of CI, including GitLab security scan jobs, external scans, compliance jobs, or other custom scripts.

General feedback related to this feature is welcome, or you may explore specific issues that have been generated within the parent epic or broader GitLab issues.

Please create a new thread with a heading, short summary, and then full description for each topic.

# Thread topic

## Short Summary

Full description

Thank you in advance for your feedback! 🙇

Feedback Summary

Status	Topic	Description	Response
⏩	Pipeline execution policy limits	Does not support > 5 compliance frameworks in a single top-level group as each security policy project will only have the first 5 pipeline execution policies evaluated	Within our 17.2 release, we kept modest limits to ensure performance. We will work to understand options for increasing limits based on usage and performance. We're exploring limits further in #498780 (closed).
⏩	CI variables	CI variables used to be injected via the project's .gitlab-ci.yml file, now it is expected to be injected via project/group CI/CD variables.	By design, pipeline execution policies are are isolated from the .gitlab-ci.yml. This helps to ensure enforcement is not dependent on and potentially manipulated by downstream project's configuration. Group CI/CD variables are recommended as this ensures the variables are inherited and cannot be modified by downstream projects. If you must configure variables to be used within the .gitlab-ci.yml, this approach may be suitable for defining variables that can be modified by project teams. Additionally, with feedback in #505481 (comment 2227959178), we released a bug fix for Override mode in the pipeline execution policy which allows for variables to be read from the .gitlab-ci.yml. Inject mode will still maintain isolation however. More control over variables and variable precedence is planned in &11797. Related issues: PEPs cannot inject configuration into project p... (#497458) #483035 (comment 2133066654)+ Enforce Custom Stages in Pipeline Execution Pol... (#475152 - closed)
⏩	Scheduled support for custom CI	Pipeline execution policies do not currently allow for enforcement of scheduled pipelines. Some use cases may be better suited for scheduled workflows rather than enforcing jobs based on triggered pipelines.	We are working to add new capability to schedule custom CI and give users more flexibility for enforcing scans in Scheduled pipeline execution policies (&14147). Note: Compliance pipelines did not support scheduled CI enforcement.
🚫	!reference	Unable to use !reference to a .gitlab-ci.yml configuration and therefore unable to utilize parallel:matrix keyword effectively to run e.g. multiple container scans all at once	There is a known issue when using !reference tags with parallel:matrix, unrelated to security policies. See here. No action currently on groupsecurity policies.
✅	ci.skip not working for pipeline execution policies	There are a number of use cases today where project teams are using ci.skip to avoid running pipelines downstream. This was blocked by PEPs to ensure compliance, but we have identified valid use cases requiring exceptions.	We completed Make [ci skip] configurable for pipeline execut... (&15647) to give users ability to configure bots/users excluded from the policy. View docs.
✅	workflow:rules defined in the policy will not merge/override the .gitlab-ci.yml but only be used in the isolated pipelines, only affecting policy jobs.	It's not yet clear if this is being leveraged and if so how deeply but we have some discussion ongoing here. A possible use case is to block use of branch pipelines in projects through the policy's workflow rules.	We completed Allow pipeline execution policies to enforce centralized workflow rules for override_ci mode to give users ability to enforce centralized workflow rules with overriding policies, such as preventing duplicate branch and MR pipelines.
🔍	includes external to pipeline execution policy configuration.	When using includes to reference configuration outside of the security policy project, access issues can limit policy execution.	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. View Documentation. It is recommended to include all necessary configuration (e.g. external includes) within the security policy project where your pipeline execution policies are managed to ensure the policy has access to read them. We will be further exploring access/permissions improvements in Add "Read Security Policies" as a permission fo... (#519764). There is not yet a planned timeline as this is in the research phase.
🚫	Container/package registry access	Similar to above, limited access for the policy to container/package registries results in challenges for policies to enforce at scale.	No action at this time.

Recent Improvements

1. Handle variables_attributes for policy pipelines (!174112 - merged) - %17.7 - This change adds support for variables_attributes for policy pipelines. This allows conditional inclusion of the project jobs when development teams decide on runtime that they only want to run compliance jobs (based on a "run variable").
2. Support stages from policies with override_proj... (!171680 - merged) - %17.7 - Support stages from policies with override_project_ci strategy. If there is a pipeline execution policy with strategy override_project_ci, we use its declared stages when we inject jobs. If there are multiple override_project_ci policies, the stages must be matching - all stages must be a subset of the largest stages set.
3. We made skip_ci configurable in Make [ci skip] configurable for pipeline execut... (&15647).
4. We made it possible for overriding policies to enforce workflow:rules in Allow pipeline execution policies to enforce ce... (#512123 - closed).
5. We added an option to handle collisions between policy and project jobs with the suffix configuration in #473189 (closed).
6. We added a feature to prevent abuse of the needs: statement to avoid required security/compliance jobs in #469256 (closed) (currently available only with FF as we continue testing and gathering feedback).
7. In 17.9 we added support for "custom stages" in #475152 (closed).