Given a pipeline is executing, when a secure token is being used, then allowlist permissions are enforced
Why are we doing this work?
When a CI_JOB_TOKEN in JWT format is presented to the REST or GraphQL API, we must enforce authorization rules based on the permissions defined in the incoming project's allowlist.
This ensures that access is restricted to only the permissions, eliminating the need to compute the list of available permissions at the time of authorization enforcement.
To achieve this, we will:
- Check if an allowlist entry exists for the job's project and deny access when it does not exist
- If it does, check if the accessed resource is governed by a policy in the
Ci::JobToken::Policies::FIXEDpolicies and grant access when it does - If it is not, check if the accessed resource is governed by a policy defined in the allowlist's
job_token_policiesand deny access when it is not
See decision diagram here.
The JWT signature will be validated by decrypting it with a trusted public key. We will then recompute the SHA256 hash of the payload and compare it to the hash in the decrypted signature. Once the token is verified as trustworthy, it will be stored in the request store to ensure it can be accessed later in the HTTP request life cycle for further authorization checks using the permissions embedded in the token.
Relevant links
Implementation plan
-
Parse and Verify the JWT -
Return the associated Ci::Buildfrom theCi::AuthJobsFinder -
Store the Token in the ::Gitlab::SafeRequestStore -
Update the Allowable#can?method to perform a authz check using the allowlist
Verification steps
-
Verify each of the API endpoints accessible by the CI_JOB_TOKENcan be authorized against using a JWT with an individual permission.-
Container registry API -
Container registry -
Deployments API -
Environments API -
Job artifacts API -
Jobs API -
Package registry -
Packages API -
Pipeline triggers -
Pipelines API -
Release links API -
Releases API -
Secure files -
Terraform plan
-