Standup new OIDC issuer for CI JWTs
Context
See discussion in: &9212 (comment 1256006253)
I'm a bit concerned about our OIDC discovery endpoint and the fact that we use the same one both for minting CI job JWT tokens and for user-facing OIDC flows. For one thing, the claims that are supported are different and there is no way to know which are supported in each case. This makes automatic probing of OIDC capabilities difficult for tooling like
glab
that may need to work across multiple instances on different versions.We'd have a bit better blast radius on CI job tokens if we had an entirely separate
iss
(issuer) to validate those against. When configuring things like workload identity federation there would be additional peace of mind knowing that you are validating against aniss
that is only used for CI. This avoids any possibility of exchanging JWT session tokens issued to end-users for cloud provider credentials.GitHub uses
https://token.actions.githubusercontent.com
as the issuer for tokens generated in Actions. They have a separate auth service athttps://github.com/login/oauth/authorize
which just implements OAuth2 and not support the full OIDC specification.
Proposed Solution
- deprecate the existing CI job JWT entirely, scheduled for removal as soon as we're allowed to do so
- stand up a new OIDC provider at
token.auth.gitlab.com
or similar - expose token exchange endpoint that accepts
CI_JOB_TOKEN
bearer token and optionalaudience
claim query param and returns a signed JWT for the CI job (i.e. #388514 (closed)) - move
id_tokens
implementation to the runner using the new token exchange endpoint