## 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. <!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION --> *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.* <!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION -->