## Problem to solve Currently a GitLab managed Terraform state can be accessed by CI jobs using the built in job token. This is restricted to jobs run by maintainers, developer jobs have read-only access. However, there are no restrictions on the branch the job is running on, which means that a maintainer can make potentially destructive infrastructure changes via a branch that was never intended to be merged. ### Intended users * [Sasha (Software Developer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sasha-software-developer) * [Devon (DevOps Engineer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#devon-devops-engineer) ## Proposal Tie protected Terraform state functionality to protected branches. Protected Terraform states can only be accessed from CI jobs running on protected branches. Access levels should be further customizable to. Who is allowed to: - read - write - local exec - lock - delete the Terraform state file. #### Happy path The CI job runs without any errors as it works today #### Protected state `terraform apply` fails with 403 - Forbidden status code. If the response allows, we should return a description for the error: "This protected state file can be changed only from protected branches using the GitLab CI." + link to docs #### Setup Protected states are enabled by default, thus they can be written only by changes made on protected branches. By default this means the `master` branch. - Existing state files are protected - If a state file is created on a protected branch, it is protected. - If a state file is created on an un-protected branch, it can be set to protected on the state details page. - If a branch is changed to be protected, any new state file changed on it turns the state protected - If a branch becomes un-protected, the state files remain protected. Removing state file protection can be done on the state details page. - Protected state files should have an icon or a tag in the state list view and in the state details page ### Proposal Add the ability to explicitly "protect" a Terraform state. Similar to protected CI variables, a protected state can only be accessed by CI jobs that are running on protected branches/tags. This will provide two additional customisation options: * The ability to prevent local execution of any kind * The ability to prevent accidental changes from branches that would never be approved and/or merged. Related but addressed in a separate issue (not in scope): * [Potentially - TBC] Prevent developers from reading the state (all access is maintainer only) - https://gitlab.com/gitlab-org/gitlab/-/issues/254668 * [Added 2020-10-29] Prevent accidental deletion of the state * [Potentially - TBC] Allow developers to write non-protected branches #### Usage ping - add a usage ping counter about the count of rules added - add a usage ping counter about the count of rules that restrict runs to the CI ### Delivery plan Expected deliverable steps could be: Initial user-facing release - Build the backend logic and database schema - it's ok to add read, write, delete, lock, local exec configuration in sequence with multiple issues - at least authorizing read, write and local exec access are required for the first GA release - DB migrations for existing states to the protected state setup: - read for developers - write for maintainers - GraphQL API to configure protected states - Instrument usage (at least with usage ping) Follow-up steps - UI to configure protected states - REST API to configure protected states - Terraform provider integration to configure protected states Not in scope (needs separate issues/epics): - instance / group level dashboard on terraform states and their protection status ### Further details ### Links / references <!-- 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 -->