Add check if user can push to protected branch with active policy
What does this MR do and why?
This MR improves check when user can push to protected branch with active policy. With this MR we are not only preventing Force Pushing, but also regular pushes when policy is active and prevent_force_pushing
approval setting is set to true
.
Screenshots or screen recordings
Scenario | Screenshot |
---|---|
Protected branch not covered by security policy | |
Protected branch covered by security policy |
How to set up and validate locally
- Upload a GitLab Ultimate license
- Add
gitlab-org
to have an Ultimate license (https://gdk.test:3443/admin/groups/gitlab-org) - Turn on the feature flag
echo "Feature.enable(:scan_result_policies_block_force_push)" | rails c
- Navigate to a project => Code => Branches
- Create a new branch called
spooky-stuff
(if you use the GDK projecthttp://gdk.test:3443/gitlab-org/gitlab-test
, it will already have it) - Ensure there is a branch called
100%branch
(if you use the GDK projecthttp://gdk.test:3443/gitlab-org/gitlab-test
, it will already have it) - Within the project navigate to Settings => Repository => Protected branches
- Protect the branches
spooky-stuff
and100%branch
. (EnableAllowed to push and merge
andAllowed to force push
settings for your user role) - NOTE: The branch names don't really matter here as long as you create two branches and protect both of them and update the test steps with the branch names you have chosen
- Navigate to "Secure" sidebar menu => Click the "Policies" sub-menu item
- Click the "New policy" button on the Policies list page
- Click "Select policy" is button name within the "Scan result policy" section
- You can either create the policy below using rule mode or click the "yaml mode" toggle button at the top of the policy editor page and copy/paste in the below yaml. The policy is applying the settings override to all protected branches except the
100%branch
(as well as the required approval for any MRs with vulnerabilities, but that is not important for this MR)
type: scan_result_policy
name: Prevent all vulnerabilities
description: ''
enabled: true
rules:
- type: scan_finding
scanners: []
vulnerabilities_allowed: 0
severity_levels: []
vulnerability_states: []
branch_type: protected
branch_exceptions:
- 100%branch
actions:
- type: require_approval
approvals_required: 1
role_approvers:
- developer
approval_settings:
prevent_pushing_and_force_pushing: true
- Save the policy using the "Configure with a merge request" button and merge the corresponding merge request.
- You will be in a different project now (the policies are saved in separate project usually), so navigate back to your original project
- Clone the project locally
- Checkout the
spooky-stuff
branch - Create a new commit by modifying any file
- Attempt to push and force-push the commit to the protected branch that is not an exception in the policy
- Verify a user gets the following error:
remote: GitLab: Push is blocked by settings overridden by a security policy
To ssh://gdk.test:2222/root/test-project-settings.git
! [remote rejected] second-branch -> second-branch (pre-receive hook declined)
- Checkout the
100%branch
(the branch that was the exception in the policy) - Verify that a user can create a new commit and push/force-push changes for that new branch with no issues
- Create/checkout a new, non-protected branch
- Verify that a user can create a new commit and push/force-push changes for that new branch with no issues
- Turn off the feature flag
- Checkout the
spooky-stuff
branch and verify that a user can create a new commit and push changes for any protected branch with no issues - Re-enable the feature flag
- Disable the policy (Secure => Policies => Select policy from list => Click "Edit policy" in the drawer, change
enabled
tofalse
=> Save the change) - Checkout the
spooky-stuff
branch and verify that a user can create a new commit and push changes for any protected branch with no issues
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.
Related to #420629 (closed)
Edited by Alexander Turinske