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
- Set up runners.
- Create a project with a working
.gitlab-ci.yml
file as the development project. - Create another project as the security policies project.
- If you are logged in as
root
pick a different user and add it as owner to both projects - Impersonate the other user
- On the development project go to Security and Compliance > Policies.
- Select Edit policy project.
- Select your security policies project.
- Select Save.
- Select New Policy.
- Select Scan execution policy
- Choose a Name.
- As Conditions Select IF Schedule actions for the branch
main
daily at 00:00. - As Actions choose SAST.
- Select Configure with a Merge Request.
- Merge the new MR
- To avoid waiting for the next day until the execution runs
- Open a rails console
- Reset the timers by
Security::OrchestrationPolicyRuleSchedule.update_all(next_run_at: Time.now - 1.day)
- Run the schedule worker
Security::OrchestrationPolicyRuleScheduleWorker.new.perform
- A new pipeline should be started on the development project and the triggerer should be the user that created the scan execution policy.
- Stop the user impersonation.
- Change the user access for the development prject to Guest
- Run the steps to execute the schedule worker again
- 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
- Create a feature flag
scan_execution_bot_users
- Add a new column
bot_user_id
to thesecurity_orchestration_policy_configurations
table. - 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 insecurity_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 ofapp/services/resource_access_tokens/create_service.rb
for this. - Modify
Security::Orchestration::UnassignService
to delete the bot user and clearsecurity_orchestration_policy_configurations.bot_user_id
. - Modify the schedule workers (
ee/app/workers/security/orchestration_policy_rule_schedule_namespace_worker.rb:25-27
andee/app/workers/security/orchestration_policy_rule_schedule_worker.rb:18
) to use instead ofschedule.owner
:if Feature.enabled(`scan_execution_bot_users`) schedule.security_orchestration_policy_configuration.bot_user || schedule.owner end
2. Make bot users optional
- Modify the
Security::Orchestration::AssignService
to take a boolean argumentcreate_project_bot
- Modify the
SecurityPolicyProjectAssign
GraphQL mutation to take thecreate_project_bot
argument and forward it toSecurity::Orchestration::AssignService
3. Frontend
- Add a checkbox to the Select security project form so users can choose to create a bot. 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
- Create a backfill migration that adds bot users to projects and groups for all records in
security_orchestration_policy_configurations
wherebot_user_id IS NULL
. - Remove the create bot checkbox.