Allow security_policy_bot to run pipelines on protected branches
requested to merge 414278-fix-security-policy-bot-pipelines-permissions-protected-branches into master
What does this MR do and why?
This change allows security_policy_bot to run pipelines on all branches, regardless of whether they are protected or not. This is necessary for scan execution policies to be able to run scheduled pipelines.
Currently, the security policy bot can only run scheduled pipelines on non-protected branches. Running it on main
leads to the following errors: logs
How to set up and validate locally
- In rails console enable the experiment fully
Feature.enable(:scan_execution_bot_users)
- Prepare the test project. Follow the steps below:
- Create a new private project with a working
.gitlab-ci.yml
file. For example, use the bash template. - Add an empty named
package.json
to the project. This is required for the SAST scan to run.
- Create a new private project with a working
- Prepare the security policy
- On the left sidebar, select Security and Compliance* and Policies.
- Select New policy.
- Select Scan execution policy
- Switch to
.yaml mode
- Replace the content with the example policy yaml below
- Select Configure with a merge request
- Select Merge.
- Go back to your initial project
- There should now be a
bot
member named GitLab Security Policy Bot.
- Wait for the next full hour until the scheduled pipeline is triggered, or trigger the job manually:
Security::OrchestrationPolicyRuleSchedule.last.update_columns next_run_at: 1.day.ago Security::OrchestrationPolicyRuleScheduleWorker.new.perform
- View the pipelines page of your project
- There should be a new pipeline triggered by the GitLab Security Policy Bot
- The pipeline should pass
Example policy yaml
type: scan_execution_policy
name: test
description: ''
enabled: true
rules:
- type: schedule
branches:
- main
cadence: 0 * * * *
actions:
- scan: sast
tags: []
MR acceptance checklist
This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.
-
I have evaluated the MR acceptance checklist for this MR.
Related to #414278 (closed)
Edited by Martin Čavoj