Support variables expansion in id_tokens:aud
Release notes
Support variables expansion in id_tokens:aud
Values of the aud
claim in id_tokens
(introduced in GitLab 15.7) can now include CI/CD variables. This enables using such JWT tokens in contexts where the aud
claim can not be a fixed value, for instance in some pipeline templates.
Problem to solve
We have several systems that we access from many CI pipelines using some (now deprecated) $CI_JOB_JWT
tokens. Some Vault servers of course, but also misc other in-house systems. In the process of migrating to id_tokens
, and adapting the target systems configuration, we've started to pay attention to the Audience/aud
claim (because id_tokens:aud
is mandatory in pipelines, and because it seems wise in general). But we've soon reached a significant pain point with current id_tokens
implementation, which supports only raw strings for aud
, with no variables expansions: most of our use cases could be nicely wrapped in pipeline templates, except we can't enable variability of the target systems URLs (choosing between several instances, or targeting a preprod environment) if they don't share the same fixed bound-Audience values (which kind of defeats the purpose of this claim).
Proposal
Long story short, we feel the need for variable expansion in id_tokens:aud
values. I see the idea was mentioned in the initial specification discussions, but unfortunately it must have been overlooked. Here is a minimal pipeline which shows it is not currently supported:
- https://gitlab.com/thomasgl-orange/test-id-tokens/-/blob/51eb4320a62f605f40f7f2f94214350609e2dd4c/.gitlab-ci.yml#L22
- https://gitlab.com/thomasgl-orange/test-id-tokens/-/jobs/4406170272#L27
...
"payload": {
"aud": "$AUD_URL",
...
FYI, alternatives we've thought of:
- stop caring about
aud
claims (after all, it was not there in$CI_JOB_JWT
), don't validate it on our target (non-OIDC) systems. That's not really satisfying, we like the idea of validating this claim to limit risk of a token being reused for some unintended purpose. - wait for Components to be in GA, probably it could solve the issues we have with
id_tokens
in CI templates, provided the GA version includes #387632 (closed). There's more uncertainty there though, as to when it will land, how easy it will be to turn our templates into components, and how smooth will be the adoption of this new feature by users who use these templates.
So, I will submit a merge-request to implement just what we need, variables expansion, because it seems both adequate and straight-forward. Variables expansion is implemented on GitLab side, and both simple strings and arrays aud
values are supported. (I mean, arrays containing variables, not the opposite of course)
Intended users
(probably not an exhaustive list)
Feature Usage Metrics
Don't know, did really think about that...