Add setting for projects to access SPP repository to fetch PEP configs
What does this MR do and why?
This change adds a project setting that allows to grant repository access to SPP project for the linked projects.
This is necessary because user may not have permission to the Security Policy Project where the linked Pipeline execution policy configuration is stored. In such case, the user is not able to run pipelines in projects where the PEP is enabled.
For follow-up MRs:
- Add a cascading group setting
- Add the settings into the UI
MR acceptance checklist
Please evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.
Screenshots or screen recordings
Before | After |
---|---|
Database
linked_to_security_policy_management_project?
With only project configurations:
Plan: https://console.postgres.ai/gitlab/gitlab-production-main/sessions/31216/commands/96963
SELECT 1 AS one FROM "security_orchestration_policy_configurations" WHERE "security_orchestration_policy_configurations"."security_policy_management_project_id" = 58486266 AND "security_orchestration_policy_configurations"."project_id" = 58486314 LIMIT 1;
Time: 3.622 ms
- planning: 0.706 ms
- execution: 2.916 ms
- I/O read: 2.830 ms
- I/O write: 0.000 ms
Shared buffers:
- hits: 3 (~24.00 KiB) from the buffer pool
- reads: 3 (~24.00 KiB) from the OS file cache, including disk I/O
- dirtied: 0
- writes: 0
With project and namespace configurations:
Plan: https://console.postgres.ai/gitlab/gitlab-production-main/sessions/31216/commands/96965
SELECT 1 AS one FROM "security_orchestration_policy_configurations" WHERE "security_orchestration_policy_configurations"."security_policy_management_project_id" = 58486266 AND ("security_orchestration_policy_configurations"."project_id" = 58486314 OR "security_orchestration_policy_configurations"."namespace_id" IN (88281517, 59720986)) LIMIT 1;
Time: 1.979 ms
- planning: 1.133 ms
- execution: 0.846 ms
- I/O read: 0.714 ms
- I/O write: 0.000 ms
Shared buffers:
- hits: 5 (~40.00 KiB) from the buffer pool
- reads: 1 (~8.00 KiB) from the OS file cache, including disk I/O
- dirtied: 0
- writes: 0
How to set up and validate locally
- Create a group
- In the group, create two subgroups:
Dev
andCompliance
- In the
Dev
group, create a projectTest
. - In the
Compliance
group, create a projectSPP
. - Inside
SPP
, create two files:-
secrets.yml
:
include: - template: Jobs/Secret-Detection.latest.gitlab-ci.yml compliance-job: stage: .pipeline-policy-post script: - 'echo "Compliance"'
-
.gitlab/security-policies/policy.yml
:
--- pipeline_execution_policy: - name: Secrets detection description: Enforce secret detection via PEP. enabled: true pipeline_config_strategy: inject_ci content: include: - project: <group-path>/compliance/spp file: secrets.yml
-
- Go to the group
Dev
-> Secure -> Policies and link the Compliance -> SPP project as security policy project - In the project
Dev
->Test
, go toPipelines
, run a pipeline and ensure that jobs from PEP are added - Add another member into
Test
project with the roleMaintainer
. - Impersonate this user and run a pipeline again
- Verify that there is "Access denied" error
- Enable the project setting:
Project.find(<SPP-project-id>).project_setting.update!(spp_repository_pipeline_access: true)
- Run a pipeline again and verify that pipeline is created with PEP jobs, although the user does not have access to
Compliance -> SPP -> secrets.yml
Related to #469439 (closed)