Skip to content

Maintainers can use Group Protected Environments API, however only Owners can manage via UI

Summary

Group Maintainers can use the Group Protected Environments API, however only Group Owners can view/edit the Group Protected Environments via UI.

Details

The permission model for the Group protected environments feature has not been changed since the introduction at 14.0. Maintainers+ can modify the entries as of today. This is the documented behavior.

However, the confusion comes from the recent UI support in 15.1 that the setting UI runs admin_group authorization on all setting items, meaning the user has to have Owner role to access the entries. Unfortunately, this gives impressions to users that the feature is not supposed to be accessible for Maintainers, but in the same time, there is no a reasonable explanation that why the entry must be restricted from Maintainers (aside from that the customer expects it to be in the way).

Proposal

  1. Change the permission model of the Group protected environments to require Owner role.
    • This could be a breaking change that users who used to modify the setting via API might encounter an authorization error.
    • This is consistent with the other group-level CI/CD settings. To prevent a further confusion, we should introduce a permission guideline that all group-level CI/CD settings require Owner role (AFAIK, this is the third time, 1st was group-level variable. 2nd was runner auth token.).
    • This aligns with the customer's expectation.

Use a feature flag to gradually rollout the change. Maybe we keep it for 1 or 2 milestones just in case. It should be default enabled, but if something went wrong, customer can disable it. Optionally, we can use two flags to Selectively disable by actor for an extra safety, which is a bit more smoother transition.

Technical details of the proposal #1

  • We move admin_protected_environment to rule { owner }.
  • Update the documentation. (We may want to additionally update the permission guideline)
  • Basically, it's same with !71965 (merged).

Further context

We considered the following proposal as well:

  1. Keep the current permission model of the Group protected environments and fix the UI.
    • Maintainers can visit "Group > CI/CD settings" but they can see Protected environment settings only (as other settings require Owner role).
    • This is consistent with the project-level protected environments that Maintainers+ can access.
    • This is consistent with the documentation, as you already pointed above.

Please note that, either way, we can't satisfy both sides, which is highlighted in this comment:

Interestingly we have the opposite scenario in Backend: Allow Group Maintainers to manage Grou... (#37930 (closed)) A group-level API is limited only to Owners and some users are asking to make it available to Maintainers. I think there's unfortunately no way to please everyone here without having more granular access control which is obviously not an easy implementation.

Related

Previous information

Steps to reproduce

  1. As a Maintainer, make an API request to protect an environment, or to list Group protected environments.
  2. As a Maintainer, attempt to access the Group Settings via UI.
  3. As a Maintainer, attempt to access manually the Groups::Settings::CiCdController via the URL https://gitlab.example.com/group-name/-/settings/cicd

Example Project

What is the current bug behavior?

  1. Maintainer is allowed to list and protect/unprotect Group-level Protected Environments.
  2. Maintainer is unable to access Group Settings via UI.
  3. Maintainer is unable to access the Groups::Settings::CiCdController via URL.

What is the expected correct behavior?

If a Maintainer can't access the UI for Group Settings, or the Groups::Settings::CiCdController, they should not be allowed to make changes associated with these settings.

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)

Possible fixes

Edited by Shinya Maeda