Prevent environment approvals rules from being removed after deployer/approver group is been deleted
Summary
Protected environment approvals rules is automatically removed after deployer or approver group is been deleted, this defeat the purpose of having approvers as segregation of duties.
Steps to reproduce
- Executor and Approver groups was invited into project to be deployed
- OperatorGroup: Executors of the deployment to the protected environment
- QA tester: Approvers for the deployment
- Security Group: Approvers for the deployment
- Multiple approval rules was configured as below.
{
"name": "production",
"deploy_access_levels": [
{
"access_level": null,
"access_level_description": "OperatorGroup",
"user_id": null,
"group_id": 19,
"id": 8,
"group_inheritance_type": 0
}
],
"required_approval_count": 0,
"approval_rules": [
{
"id": 9,
"user_id": null,
"group_id": 17,
"access_level": null,
"access_level_description": "QA tester",
"required_approvals": 1,
"group_inheritance_type": 0
},
{
"id": 10,
"user_id": null,
"group_id": 18,
"access_level": null,
"access_level_description": "Security Group",
"required_approvals": 1,
"group_inheritance_type": 0
}
]
}
- Upon removing one of the executor or approver group and pinging the 'multiple approval rules' via API shows that the rules are been changed; executor or approver rule is been removed correspondingly.
[
{
"name": "production",
"deploy_access_levels": [],
"required_approval_count": 0,
"approval_rules": [
{
"id": 13,
"user_id": null,
"group_id": 17,
"access_level": null,
"access_level_description": "QA tester",
"required_approvals": 1,
"group_inheritance_type": 0
},
{
"id": 14,
"user_id": null,
"group_id": 18,
"access_level": null,
"access_level_description": "Security Group",
"required_approvals": 1,
"group_inheritance_type": 0
}
]
}
]
Example Project
I can't create example project on GitLab.com as this requires multiple accounts, this was reproduced on my self-managed instance and a shared over a zoom session was with @shinya.maeda
What is the current bug behavior?
The executor or approver rule is deleted automatically, without informing the related parties.
What is the expected correct behavior?
You should not allow the deletion of users/groups if they are related to an executor or approver rules.
Relevant logs and/or screenshots
Output of checks
Results of GitLab environment info
Expand for output related to GitLab environment info
(For installations with omnibus-gitlab package run and paste the output of: `sudo gitlab-rake gitlab:env:info`) (For installations from source run and paste the output of: `sudo -u git -H bundle exec rake gitlab:env:info RAILS_ENV=production`)
Results of GitLab application Check
Expand for output related to the GitLab application check
(For installations with omnibus-gitlab package run and paste the output of:
sudo gitlab-rake gitlab:check SANITIZE=true
)(For installations from source run and paste the output of:
sudo -u git -H bundle exec rake gitlab:check RAILS_ENV=production SANITIZE=true
)(we will only investigate if the tests are passing)
Solution
- When a user/group is deleted, we keep the deployment approval rule - but have it set to an invalid state.
- When a user visits the Protected Environment Settings, they are shown the following error on the row of the rule that is now invalid. They are promoted to either edit or delete the affected rule.
Proposal | With Tooltip |
---|---|
![]() |
![]() |
Backend Proposal
In order to put a deployment approval rule into an invalid state, we have to make a few changes around as follows.
- Upon user/group deletion, update a deployment approval rule's
access_level
toGitlab::Access::NO_ACCESS
. - Ensure
ProtectedEnvironments::Authorizable#check_access
returnsfalse
forGitlab::Access::NO_ACCESS
(see below).