Automatically provide credentials to CI via Specialized token
Release Post candidate
Changing an infrastructure is always a high-risk action, as a result it should be supervised, audited and allowed only to experienced team members. Last month we've introduced the GitLab managed Terraform state, and we knew it had a limitation. You were required to provide an access token to work with the state file. This option clearly did not scale well.
Starting with GitLab 13.1, we are introducing a new job token that is auto-generated with the acting users credentials and is designed to run Terraform state management jobs specifically. This way, our users can have flexible and secure Terraform job pipelines without any extra setup required.
Problem to solve
As a Junior Operator, I want to commit my changes to the repo and see the expected output (terraform plan
), so that my changes are safe to be reviewed.
As a Senior Operator responsible for the infrastructure, I want to accept infrastructure changes and update the state of my infrastructure (terraform apply
), so that infrastructure is managed by code.
Intended users
- Sasha (Software Developer)
- Devon (DevOps Engineer)
- Sidney (Systems Administrator)
- Allison (Application Ops)
- Priyanka (Platform Engineer)
User experience goal
- User should be able to use TF backend without configuring a personal access token.
- The user should be able to use CI jobs with appropriate access rights to the Terraform state API endpoints.
Definition of Done
Iteration 1
-
User can leverage inherent TF_JOB_TOKEN
instead of configuring a bespoke access token. -
GitLab CI can use TF_JOB_TOKEN
to configure TF state backend. -
Documentation updated to reflect TF_JOB_TOKEN
usage.
Next Iteration
Either extend CI_JOB_TOKEN
to include at least partial API rights or create a specific TF_JOB_TOKEN
for the task that receives the current user's authorizations for the Terraform API endpoints and is invalidated at the end of every job run.
- Developer role: can read the state (
terraform plan
) - Maintainer role: can write the state (
terraform apply
)
Further details
Permissions and Security
Documentation
Availability & Testing
What does success look like, and how can we measure that?
What is the type of buyer?
Is this a cross-stage feature?
Links / references
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.