Use project bot users to run scan execution policies pipelines

What does this MR do and why?

This MR adds a:

• Feature flag scan_execution_bot_users.
• Column bot_user_id to security_orchestration_policy_configurations.
• Bot user type security_policy_bot.
• Worker to create bot users and add them as guest to a project.
• Change to run the worker whenever a new Security::OrchestrationConfiguration is assigned.

With the Feature flag scan_execution_bot_users enabled. With every new security configuration is assigned to a project, it should create a bot user and add it as a guest to the project.

In the next iteration, we want to use the bot user to trigger scan execution pipelines. Currently, the last user that edited the security policy project is used as a triggerer for the pipelines.

Related issue #394958 (closed)

Screenshots or screen recordings

Screenrecording coming soon.

How to set up and validate locally

There are 4 cases to validate:

Preparation

1. Switch to the andysoiron/security-scan-results-policy-bots branch
2. Run migrations rails db:migrate
3. Restart GDK
4. Enable the feature flag Feature.enable(:scan_execution_bot_users)
5. Create a new project.

1. Assign a security policy project

1. On the right sidebar, select Security and Compliance* and Policies.
2. Select Edit policy project.
3. Choose any project and select Save.
4. On the right sidebar, select Project information* and Members.
5. There should now be a bot member named GitLab Security Policy Bot.

2. Change the security policies project

1. On the right sidebar, select Security and Compliance* and Policies.
2. Select Edit policy project.
3. Choose any project other and select Save.
4. On the right sidebar, select Project information* and Members.
5. The bot user should still be there GitLab Security Policy Bot.
6. Select the username to get to the user page.
7. Remember the user ID
8. Find your project ID and copy it.
9. Look up the Security::OrchestrationPolicyConfiguration for the project

   Project.find(YOUR_PROJECT_ID).security_orchestration_policy_configuration

10. The bot_user_id field should match the ID of the bot user.

3. Remove the security policies project

1. On the right sidebar, select Security and Compliance* and Policies.
2. Select Edit policy project.
3. Select the trash can symbol next to the security policies project name.
4. Select Save.
5. On the right sidebar, select Project information* and Members.
6. The GitLab Security Policy Bot user should be removed.

4. Remove a bot user member

1. On the right sidebar, select Security and Compliance* and Policies.
2. Select Edit policy project.
3. Choose any project and select Save.
4. On the right sidebar, select Project information* and Members.
5. There should now be a bot member named GitLab Security Policy Bot.
6. Select the three dots (more actions) icon on the right side of the member entry.
7. Select Remove Member.
8. Select Remove Member from the popup window again.
9. Find your project ID and copy it.
10. Look up the Security::OrchestrationPolicyConfiguration for the project

    Project.find(YOUR_PROJECT_ID).security_orchestration_policy_configuration

11. The bot_user_id field should be nil.

Database

Rollback migrations:

rails db:migrate:down:main VERSION=20230419192748
rails db:migrate:down:ci VERSION=20230419192748
rails db:migrate:down:main VERSION=20230419193807
rails db:migrate:down:ci VERSION=20230419193807
rails db:migrate:down:main VERSION=20230425124907
rails db:migrate:down:ci VERSION=20230419193807

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.

app/models/user.rb

@@ -2233,7 +2233,7 @@ def trust_scores_for_source(source)
 
   # override, from Devise::Validatable
   def password_required?
-    return false if internal? || project_bot?
+    return false if internal? || project_bot? || security_policy_bot?
 
     super
   end