Group-level permissions config for Protected Environments
Timeline
-
Deliver alpha version of this feature. (Due date: 31th May - 14.0 milestone) -
Feature Flag Issue => #331085 (closed)
-
-
Wait for a customer to verify the feature is viable solution in their SLDC workflow. (Due date: June?) -
Make the feature GA by removing the feature flag and officially announcing in a release blog post. (Due date: July?)
Problem
Typically, large enterprise organiations have an explicit permission boundary between developers and operators. Developers build and test their code/application, and operators deploy and monitor the application. The permission of each group is carefully configured in order to avoid unauthorized users gain an access to a critical component.
Speaking this permissions in Continuous Deployment/Delivery (CD) context, we can illustrate the permissions of allowance of deployments in the following table:
Environment | Developer | Operator | Category |
---|---|---|---|
Development | Allowed | Lower Environment | |
Testing | Allowed | Lower Environment | |
Staging | Disallowed | Allowed | Higher Environment |
Produciton | Disallowed | Allowed | Higher Environment |
(Reference: Deployment environments)
GitLab CD has a bunch of deployment safety features to ensure that the deployments can only be proceeded by the right group at the right time. However, we don't have a solution at the organization/group-level yet. In a large organization, they host thousands of projects under the group, so for example, making sure that all of the project-level protected environments are properly configured is not scalable solution. Developers might accidentally change the configuration.
Proposal
We introduce a group-level deployment permission configuration. This is conceptually same with protected environments, but this feature is built at group-level. Here are the main points of the feature spec:
- Users who have maintainer role (or above) at a group can access to the group-level protected environments configuration.
- Users who have developer role (or below) at a group can NOT access to the configuration.
- If a deployer is about to run a deployment job in a project and allowed to deploy to the environment, the deployment job will be proceeded.
- If a deployer is about to run a deployment job in a project but disallowed to deploy to the environment, the deployment job fails with a message.
- Regarding sub-groups (i.e. a group under a group), if a higher group has configured the group-level protected environment, the lower groups can't configure it, and if it's already existing, it'll be ignored.
- Project-level protected environments can be combined with this feature. If both group-level and project-level environments configurations exist, the deployer must be allowed in both rulesets. The project-level config is still used by developers to do a fine-graned tuning for their lower environments, but still, they can't access to the higher environments.
This feature is GitLab Premium.
The GitLab Roles in a group, sub-groups and belonging projects
The idea of this approach is to separete the operator's resource and developer's resource by depending on the group > project hierarchy, meaning that the organization must properly configure the GitLab Roles. Here is an example of role setup:
-
Operator group is assigned to the top-level group as
Maintainer
role, meaning they can configure the oraganization-wide deployment ruleset. -
Develoepr group is assigned to the top-level group as
Developer
role, meaning they don't have an access to the configuration. - In a subsequent project of the group, developer group can be promoted to
Maintainer
role, meaning they have an access to project configuration to setup deployments to lower environments.
(Alternatively solution is fully customizable RBAC, however, this takes time to achieve)
The ruleset specification
The group-level configuration can have multiple rules, and a rule contains the following paramter:
Name | Type | Description |
---|---|---|
Deployment Tier | Enum | One of production , staging , testing , development or other . See more in the doc. |
Allowed to deploy | Roles/Users/Groups | GitLab Roles (Developers + Maintainers or Maintainers), specific users or groups. |
Example configuration:
Deployment Tier | Allowed to deploy |
---|---|
production |
@operator-group |
staging |
@operator-group |
Configuration interface
Users can configure the group-level protected environments via multiple ways.
- Rest API
- GraphQL API (Out of scope)
- UI. Visit Group > Settings > CI/CD > Protected Environments. (Out of scope) => #325249 (closed)
old proposal
## ProblemProtected environments is a great way of designating certain environments with a higher level of scrutiny. However, some organizations would like a greater level of protection over these environments.
Currently, Maintainers are allowed to make changes to these settings; some organizations give out Maintainer access frequently to allow them to push to protected branches, but deploying to a production environment needs additional scrutiny.
Proposal
Introduce a group-level setting for group Owners to designate who can modify Protected Environment settings in a project:
- Maintainers and Owners (default)
- Owners only
The group level setting will be similar to the project level setting
Users with the right permissions can assign specific Users, Groups or roles to deploy to protected environments.
This setting will aggregate to any project that is associated within this group of projects.
If this setting is used. The project level protected environment will be disabled or hidden and cannot be set and the API requests should fail as well.
If a project is removed from the group, the setting for protected environment shall be available in the projects level.
cc @vehernandez @jmeshell
Release Notes
To be Written