Skip to content

Allow pipeline execution yaml files to be read by projects linked to security policy projects during pipeline execution

Release post

We've introduced a new setting for security policies that allow you to grant read access to pipeline-execution.yml files for all linked projects. This setting provides more flexibility for enabling any users, bots, or tokens to enforce pipeline execution globally across projects, such as ensuring group or project access tokens can read security policy configurations to trigger pipelines during pipeline execution for a pipeline execution policy. Users will still not be able to view the security policy project repository or YAML directly. The configuration is only used during pipeline creation.

Summary

A large Ultimate, SaaS customer is experiencing this bug with Intermittent pipeline failures with the error "Project ((company name)/security/security-scan-policies/security-policy-project not found or access denied! Make sure any includes in the pipeline configuration are correctly defined." But the policy project exists.

Steps to reproduce

https://gitlab.zendesk.com/agent/tickets/508085

What is the current bug behavior?

Intermittent pipeline failures with the error "Project (company name)/security/security-scan-policies/security-policy-project not found or access denied! Make sure any includes in the pipeline configuration are correctly defined." But the policy project exists.

What is the expected correct behavior?

Customer created a GAT in the main group with a Maintainer role and used it to issue a test commit to trigger the pipeline and it worked. If any project triggers the pipeline with a project or Group Access Token encounters a pipeline failure, then we need to use the Global Group access token.

They want GitLab to find an ideal solution (provide anonymous read access to the policy project for the pipelines).

Relevant logs and/or screenshots

https://gitlab.zendesk.com/agent/tickets/508085

Output of checks

This bug happens on GitLab.com /label reproduced on GitLab.com

Results of GitLab environment info

https://gitlab.zendesk.com/agent/tickets/508085

 

(For installations with omnibus-gitlab package run and paste the output of: \\\`sudo gitlab-rake gitlab:env:info\\\`) (For installations from source run and paste the output of: \\\`sudo -u git -H bundle exec rake gitlab:env:info RAILS_ENV=production\\\`)

Results of GitLab application Check

Expand for output related to the GitLab application check 

(For installations with omnibus-gitlab package run and paste the output of: \`sudo gitlab-rake gitlab:check SANITIZE=true\`) (For installations from source run and paste the output of: \`sudo -u git -H bundle exec rake gitlab:check RAILS_ENV=production SANITIZE=true\`) (we will only investigate if the tests are passing)

Possible fixes

Verification steps

  1. Create a project which will serve as security policy project with private access
  2. Create a file policy-ci.yml: 
    policy-job:
  stage: .pipeline-policy-post
  script:
    - echo 'Policy job'
  3. Create another project
  4. In this project, link the SPP project from step 1.
  5. Create a new Pipeline execution policy and choose policy-ci.yml from the SPP project
  6. Grant access to a test user with a maintainer role to the test project where the policy is enforced
  7. Try to run a pipeline and verify that it fails due to denied access to the SPP
  8. Go to the SPP -> Settings -> General and enable the new setting
  9. Try to run a pipeline again and verify that it runs.
Edited by Martin Čavoj