Protected environments

Description

Some environments, such as production, should be protected so that only qualified people can affect them. This is particular important for manual actions such as deploy to production, but could apply to automatic actions as well. This is similar, but slightly different than protected branches. Depending on how protected branches evolves, protecting environments may not be necessary. Or vice versa.

Proposal

• Use an interface similar to protected branches

User should be able to:

1. Determine at a glance if an environment is protected or not
2. Once you drill down into the environment, see who has permission to deploy to this environment
3. If user has the proper role/access, protect/unprotect and environment
4. If user has proper role/access, add roles/users to the "allowed to deploy" list

Links

• Related gitlab-ce#17986, gitlab-ce#17633

Documentation blurb

Environments can be used for different scopes, so some of them are just for testing while others are for production. As deploy jobs could be raised by different users with different roles, it is very important that specific environments are "protected" to avoid unauthorized people to affect them. This feature ensures that only people with the right privileges can deploy code to the "protected" environments, keeping them safe.

Permissions (without protection)

By default, developer, maintainer, and owner role are able to deploy to environment as they can run CI/CD pipeline jobs.

	Guest	Reporter	Developer	Maintainer	Owner
List environments		Y	Y	Y	Y
View environment		Y	Y	Y	Y
Edit environment				Y	Y
Delete/close environment				Y	Y
See deploy board		Y	Y	Y	Y
See pod logs			Y	Y	Y
See metrics		Y	Y	Y	Y
Configure metrics & alerts				Y	Y
Terminal				Y	Y
Deploy to environment			Y	Y	Y

Permissions (with protection)

When protected, maintainer and owner will be able to deploy to environment, although that is configurable.

	Guest	Reporter	Developer	Maintainer	Owner
List environments		Y	Y	Y	Y
View environment		Y	Y	Y	Y
Edit environment				Y	Y
Delete/close environment				Y	Y
See deploy board		Y	Y	Y	Y
See pod logs			Y	Y	Y
See metrics		Y	Y	Y	Y
Configure metrics & alerts				Y	Y
Terminal				Y	Y
Deploy to environment				Y*	Y*

* default permissions is configurable and can be removed if desired

UX Proposal

Project settings

Within project CI/CD settings, we'll include another section for Protect Environments settings. This will allow users to choose an environment to protect. An environment can be protected by selecting Maintainers, an individual user(s), or a group(s) that is shared with the project. We can also include No one which should deselect other options that were selected.

• Select No one, all other options are deselected.
• If you have No one selected, and select another criteria, No on should be deselected
• Select Maintainers, input reads Maintainers
• Select Maintainers + 1 Group, input reads 1 role, 1 group
• Select Maintainers + 1 Group + 2 users, input reads 1 role, 1 group, 2 users
• Select 2 Groups + 1 user, input reads 2 groups, 1 user
• Select 2 Groups, input reads 2 groups
• Select 1 user, input reads 1 user

Protected environments settings	Dropdown

To reduce scope, we can choose to not include No one in the MVP since the current functionality for protected branches is partially broken for No one.

Wildcards

Environments with wildcard entries will not be supported as part of the Protected Environments MVC

Environment overview page

Within the environments page, we will show a badge that reads protected. This is the same functionality that is used for protected environments. Users without permissions won't see the deploy options.

No environment is protected by default.

With permissions	Without permissions

CI Job

If a user doesn't have permissions to deploy to a particular environment, the CI job will fail.

Job

There will be no trace as the job won't be picked up by the runner.

This page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.