"aud" claim should be list, not string

[sergiustheblack]

"aud" claim should be list, not string

[sergiustheblack]

Is it sufficient to simply not configure a required audience in the Vault k8s auth role for this case?

It works well without audience configured at Vault side and no customization in SecretProviderClass.

requirements/considerations that make that undesirable?

To address this I probably need to dive deeper inside JWT, k8s, Vault auth flows. Until now I considered audience is an additional mechanism of distinguishing Vault permissions between applications, deployed to the cluster (alongside service account and namespace).

[tomhjp]

Thanks for raising this. Note there is some relevant previous discussion here: #144 (comment)

I can see how the https://kubernetes.default.svc/ audience is required, so that the Kubernetes API accepts the token. I don't yet understand the need for the app audience. Would you be able to expand on that requirement a bit please?

[sergiustheblack]

Thanks for raising this. Note there is some relevant previous discussion here: #144 (comment)

I can see how the https://kubernetes.default.svc/ audience is required, so that the Kubernetes API accepts the token. I don't yet understand the need for the app audience. Would you be able to expand on that requirement a bit please?

"app" is just an example of custom audience in my case. It is configured as role's required audience at Vault side.
Thanks.

[tomhjp]

Thanks, but why is app configured as the role's required audience in Vault? Vault's audience config is optional, and Kuberentes' API documentation explains the audience field pretty well:

Audiences are the intended audiences of the token. A recipient of a token must identify themself with an identifier in the list of audiences of the token, and otherwise should reject the token.

i.e. if you were going to specify any additional audience, I would expect it to be an audience that Vault itself identifies as, not the app. It goes on to say:

A token issued for multiple audiences may be used to authenticate against any of the audiences listed but implies a high degree of trust between the target audiences.

So I could imagine a case where multiple audiences are desirable for specifying Vault and Kubernetes audiences, and those seem like somewhat reasonable things to have a high degree of trust between. Through this lens I don't see a case to set an app as the audience, because the app and the Kubernetes API operate at very different layers in the application stack, as well as the app not being the intended audience for the token.

That brings me to my question: Is it sufficient to simply not configure a required audience in the Vault k8s auth role for this case? Or are there requirements/considerations that make that undesirable?