JWT aud claim should be dynamic.

[elinesterov]

What feature do you want to see added?

In the current implementation, the audience claim is static, which means that the administrator can configure the OIDC issuer to only a specific audience, which is very limiting. I want my job to be able to authenticate to AWS but also to Vault, and in this case, I need the option to have a different audience.

The process of requesting tokens should be able. to specify audience claim depending on the party is going to use the talking for (Vault vs. AWS STS)

Upstream changes

No response

[jglick]

Not sure I follow the use case. Why not just define one credentials item for AWS and one for Vault?

[dee-kryvenko]

I can answer that @jglick, I was looking into this plugin as well just now. Because of the role of "jenkins administrator" with ability do define credentials entry != a role of the "job administrator" who is just a regular user supplying a Jenkinsfile. Current implementation requires a user to contact admins and request a separate credentials entry for each use case. There is not a reason for that. There in fact should be no credential entry at all. This should be just a step that injects JWT to the current job with no corresponding credentials entry. And aud claim is a claim that can and should be modifiable by users as input to that step. Example of GitHub Actions implementation: https://docs.github.com/en/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect

By default, this is the URL of the repository owner, such as the organization that owns the repository. You can set a custom audience with a toolkit command: core.getIDToken(audience)

I can't seem to find this in plain text in RFC, but it is a common understanding that the aud claim, unlike other claims, should not be protected from user. It is true that the user should not be able to modify claims that are identifying the user, i.e. sub. But aud claim identify the consumer of the token, it is a job of the consumer (i.e. AWS IAM trust policy) to validate both the identity of the user (i.e. sub claim) and wether the token was meant for AWS or not (i.e. aud claim which BTW your IAM trust policy can require non-standard value for it). Besides the GitHub Actions, many other OIDC IdP doing the same thing.

[dee-kryvenko]

Actually, as I only explained why it is safe to allow the untrusted user to modify the aud claim - I should also explain why this is unsafe not to allow that. The user might also be the owner of the consumer resource. Example - user is the owner of the job, have no admin access on Jenkins, but also is the owner of their IAM roles. Which there are more than one. If user can't modify any claims at all, any of their JWT will be able to assume any of their IAM roles, which might not be secure for the user. A user might want different stages running different untrusted code to only be able to assume certain roles. This is a typical use case, a user would override IAM trust condition to use different aud values per stage. Imagine if GitHub Actions did not allow us to override aud claim and would always enforce their "safe" value. Not only it doesn't makes sense, then the aud claim has no function as it just becomes duplicative of sub and iss, but it makes it completely unusable because every consumer (AWS, GCP, Azure, K8s) will require different aud.

[jglick]

Would have to think about the implications. BTW “job administrators” can be permitted to define credentials at folder level.

[dee-kryvenko]

Another example https://kubernetes.io/docs/concepts/storage/projected-volumes/#serviceaccounttoken As a cluster user with ability to create pods, you can request cluster issuer for arbitrary aud as well.

[dee-kryvenko]

BTW “job administrators” can be permitted to define credentials at folder level.

That is not always the case, in my scenario "folders" are GitHub Org folders with many "tenants" inside each folder. Users generally only able to supply Jenkinsfile and not much more than that.

[dee-kryvenko]

Expiration claim should also be customizable by the user.