Skip to content

Use bot users to trigger scan execution policies pipelines

Summary

Scan execution policies can trigger pipelines on projects. As the user triggering the pipeline, we use 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.

This issue is the result of a spike issue: #384322 (closed)

Related feature flag: [Feature flag] Rollout `scan_execution_bot_users` (#409459 - closed)

Release post

Security bot users can now be created to support in managing background tasks to enforce security policies. This will ease the process for security and compliance team members to configure and enforce policies, specifically removing the need for security policy project maintainers to also maintain Developer access in development projects.

When creating or modifying a security policy project, you will be able to opt-in to create a security bot user for the project.

Steps to reproduce

  1. Set up runners.
  2. Create a project with a working .gitlab-ci.yml file as the development project.
  3. Create another project as the security policies project.
  4. If you are logged in as root pick a different user and add it as owner to both projects
  5. Impersonate the other user
  6. On the development project go to Security and Compliance > Policies.
  7. Select Edit policy project.
  8. Select your security policies project.
  9. Select Save.
  10. Select New Policy.
  11. Select Scan execution policy
  12. Choose a Name.
  13. As Conditions Select IF Schedule actions for the branch main daily at 00:00.
  14. As Actions choose SAST.
  15. Select Configure with a Merge Request.
  16. Merge the new MR
  17. To avoid waiting for the next day until the execution runs
    1. Open a rails console
    2. Reset the timers by Security::OrchestrationPolicyRuleSchedule.update_all(next_run_at: Time.now - 1.day)
    3. Run the schedule worker Security::OrchestrationPolicyRuleScheduleWorker.new.perform
  18. A new pipeline should be started on the development project and the triggerer should be the user that created the scan execution policy.
  19. Stop the user impersonation.
  20. Change the user access for the development prject to Guest
  21. Run the steps to execute the schedule worker again
  22. There should not be a new pipeline in the development project because the user doesn't have access anymore.

Previous attempt to fix this

We tried to fix this with !103544 (merged). This would create a bot user to trigger pipelines and bypass the permission check if the user is of type security_policy_bot . But it got reverted because it caused issues in accessing registry.

Implementation plan

We can fix this issue by creating a bot user on each project or group that is linked to a security policy project. Those users would have the necessary permissions to run pipelines and access registry. For this we can add a checkbox to the link security policy form. If checked, this will create and use the bot user, otherwise fall back to use the schedule owner as the triggerer of the pipeline:

Iterations

1. Create and use bot users

  1. Create a feature flag scan_execution_bot_users
  2. Add a new column bot_user_id to the security_orchestration_policy_configurations table.
  3. If the FF is enabled, create a new user with type security_policy_bot for the project or group. The bot user ID can be stored in security_orchestration_policy_configurations.bot_user_id. This has to be a find_or_create action in case a bot already exists. We might be able to re-use parts of app/services/resource_access_tokens/create_service.rb for this.
  4. Modify Security::Orchestration::UnassignService to delete the bot user and clear security_orchestration_policy_configurations.bot_user_id.
  5. Modify the schedule workers (ee/app/workers/security/orchestration_policy_rule_schedule_namespace_worker.rb:25-27 and ee/app/workers/security/orchestration_policy_rule_schedule_worker.rb:18) to use instead of schedule.owner: 
    if Feature.enabled(`scan_execution_bot_users`)
  schedule.security_orchestration_policy_configuration.bot_user || schedule.owner
end

2. Make bot users optional

  1. Modify the Security::Orchestration::AssignService to take a boolean argument create_project_bot
  2. Modify the SecurityPolicyProjectAssign GraphQL mutation to take the create_project_bot argument and forward it to Security::Orchestration::AssignService

3. Frontend

  1. Add a checkbox to the Select security project form so users can choose to create a bot. Screenshot_2023-03-07_at_20.25.06 if the FF is enabled.

4. Feature flag rollout

Come up with a strategy to enable the feature flag and measure success.

Alternative solution

If the opt-in solution, with checkbox turns out to be too confusing, we can create a backfill migration to create bot users for existing projects.

Implementation plan

  1. Create a backfill migration that adds bot users to projects and groups for all records in security_orchestration_policy_configurations where bot_user_id IS NULL.
  2. Remove the create bot checkbox.
Edited by Andy Schoenen