## Why are we doing this work Similar to https://gitlab.com/gitlab-org/gitlab/-/issues/418745, we would like to secure _group_-level Protected Branches from modification or removal when the Scan Result Policy is enabled with the `block_unprotecting_branches` setting enabled for matching branch. Because a group contains a potentially large number of projects, we might have to check a large number of branches to determine if a group-level protected branch can be modified. This in turn will require a large number of Gitaly calls, since branches are not cached. ## Relevant links * [Epic](https://gitlab.com/groups/gitlab-org/-/epics/9705 "Prevent branch modification when a policy disables the setting for the given branches") * [Design](https://gitlab.com/gitlab-org/gitlab/-/issues/388673 "🎨 Design: Prevent users from unprotecting branches with at least one active security policy") * [Related Epic](https://gitlab.com/groups/gitlab-org/-/epics/9567 "Allow users to define branch exceptions to enforced security policies") * https://gitlab.com/gitlab-org/gitlab/-/issues/418745#note_1493748639 ## Non-functional requirements - [x] Documentation: changes should be documented in Protected Branches and Scan Result Policies sections of the documentation, - [x] Feature flag: this feature should be released behind feature flag - [ ] Performance: - [x] Testing: - test that you are not able to modify/delete a group-level protected branch when `block_unprotecting_branches` is set to `true` for policy, the Scan Result Policy is configured on the Project-level for protected branches, - test if you are able to modify/delete a group-level protected branch when `block_unprotecting_branches` is set to `false` for policy, the Scan Result Policy is configured on the Project-level for protected branches, - test if you are able to modify/delete a group-level protected branch when `block_unprotecting_branches` is set to `true` for policy, the Scan Result Policy is configured on the Project-level for selected protected branches, but you are modifying not-selected branch, - etc. ## Implementation plan Introduce `block_branch_modification` setting in YAML, along with an option to set exceptions for group-level branch (wildcard? regex?) patterns. ```yaml type: scan_result_policy name: Dummy policy enabled: true rules: - type: any_merge_request branches: [master main] commits: any approval_settings: block_branch_modification: true block_group_branch_modification: enabled: true exceptions: [acme-corp/development] ``` --- Smenaitcs see: https://gitlab.com/gitlab-org/gitlab/-/issues/420724#note_1673365361 >Modification of branch protection is blocked for a group if there is at least one blocking policy that applies to it and: > >* The policy sets `block_branch_modification: true` and it does not set `block_group_branch_modification: false` >* The policy sets `block_group_branch_modification: true` >* The policy sets `block_group_branch_modification.enabled: true` and `block_group_branch_modification.exceptions` does not include the group's full path --- For the policy editor, we will implement the design as follows:  ## Implementation Plan * ~backend: A PoC is available on the [`420724-be-prevent-changes-in-group-level-protected-branches-when-policy-settings-are-enabled`](https://gitlab.com/gitlab-org/gitlab/-/compare/master...420724-be-prevent-changes-in-group-level-protected-branches-when-policy-settings-are-enabled?from_project_id=278964&straight=false) branch ## Verification steps 1. Create a new group with a protected branch 2. Create a new contained project 3. Create a new Scan Result Policy for this project that should be applied to protected branches (make sure `block_branch_modification` is set to `true`) 4. See if you can modify the group-level Protected Branch in groups's Settings (you should not be able to do it)