Create ID token variables and pass one to the runner
What does this MR do and why?
This is the 2nd MR for #356986 (closed).
This MR makes 3 changes:
- It defines custom JWT variables for CI builds that have ID tokens configured
- When the project CI/CD setting
opt_in_jwt
istrue
(it isfalse
by default), it does not define default JWT variables for CI builds - When the project CI/CD setting
opt_in_jwt
istrue
and ID tokens are configured, it uses the first ID token to authenticate with Hashicorp Vault when fetching secrets adds functionality to generate variables with JWT values for each ID token configured for a CI build.
Screenshots or screen recordings
We have a Hashicorp Vault with an authentication configuration that responds to an audience of developers
(see bound_audiences
)
By default and before this MR, a GitLab instance uses its own base URL as the audience claim for a JWT: https://gitlab.com/gitlab-org/gitlab/-/blob/20482887faa40ea8abd155a52651eb99a57bab80/lib/gitlab/ci/jwt_v2.rb#L12
So when we have a job configured to fetch a secret from the Vault
test_secrets:
variables:
VAULT_AUTH_PATH: gitlab
VAULT_AUTH_ROLE: gitlab-test-role
VAULT_SERVER_URL: http://172.16.123.1:8200
secrets:
DATABASE_PASSWORD:
vault: gitlab-test/db/password
script:
- echo $DATABASE_PASSWORD
- cat $DATABASE_PASSWORD
The job fails
It won't be possible to configure a job with an ID token that has the right audience until the next MR for this feature, so for now we will update the job's ID tokens in the console
When we retry the job, it succeeds!
How to set up and validate locally
It's quite complicated to test this locally, so reviewers are not expected to test functionality that communicates with Vault until #369351 (closed) is completed
MR acceptance checklist
This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.
-
I have evaluated the MR acceptance checklist for this MR.