Skip to content

Use security_policy_bot users to start pipelines

What does this MR do and why?

This is the second step towards running security scan execution pipelines as bot users.

Scan execution policies can trigger pipelines on projects. The user that triggers the pipeline, is the last user that modified the security policy project. This user might not have the permission to start a pipeline on the linked project, though. To fix it, we want to create a bot user on every project that has a security policy. This bot user will then be the user to trigger the pipelines.

In the previous MR I added the functionality that creates the bot user. This MR will use the bot user, if it exists, to trigger the pipeline. It:

  • Gives bot users the right access to run pipelines
  • Starts scan execution pipelines as the bot user

There is one bug in this MR: Pipelines will not be triggered for protected branches because the access check for this is not based on policies. I'm going to fix this bug in one of the next MRs before we enable the feature flag.

Related to #394958 (closed)

How to set up and validate locally

📺 Screen recording: https://www.youtube.com/watch?v=yhVLpdkdoEU

  1. Prepare your environment
    1. Switch to the andysoiron/security-scan-results-policy-bots-use-for-workers branch
    2. Restart GDK
    3. Enable the feature flag Feature.enable(:scan_execution_bot_users)
  2. Prepare the test project. Follow the steps below or clone https://gitlab.com/gitlab-org/govern/security-policies/andys-test-group/scan-execution-policy-test
    1. Create a new project with a working .gitlab-ci.yml file. For example, use the bash template.
    2. Add an empty named package.json to the project. This is required for the SAST scan to run.
    3. On the left sidebar select Repository and Branches
    4. Select New branch
    5. Enter test as name
    6. Select Create branch
  3. Prepare the security policy
    1. On the left sidebar, select Security and Compliance* and Policies.
    2. Select New policy.
    3. Select Scan execution policy
    4. Switch to .yaml mode
    5. Replace the content with the example policy yaml below
    6. Select Configure with a merge request
    7. Select Merge.
    8. Go back to your initial project
    9. There should now be a bot member named GitLab Security Policy Bot.
  4. Start a rails console and trigger the OrchestrationPolicyRuleScheduleWorker:
Security::OrchestrationPolicyRuleSchedule.update_all(next_run_at: Time.now - 1.day)
Security::OrchestrationPolicyRuleScheduleWorker.new.perform
  1. View the pipelines page of your project
  2. There should be a new pipeline triggered by the GitLab Security Policy Bot

Example policy yaml

type: scan_execution_policy
name: test
description: ''
enabled: true
rules:
  - type: schedule
    branches:
      - test
    cadence: 0 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.

Edited by Andy Schoenen

Merge request reports

Loading