"aud" claim should be list, not string

[sergiustheblack]

We use Vault Server external to EKS cluster with kubernetes auth with short-lived tokens (See https://developer.hashicorp.com/vault/docs/auth/kubernetes#use-the-vault-client-s-jwt-as-the-reviewer-jwt). Valid JWT contains the following part

  "aud": [
    "https://kubernetes.default.svc"
  ],
...
}

In order to use external Vault with customized audience, audience claim must contain this string "https://kubernetes.default.svc".
When customizing audience, it is rewritten completely, what makes kubernetes auth with short-lived tokens broken.
Config:

apiVersion: secrets-store.csi.x-k8s.io/v1
kind: SecretProviderClass
metadata:
  name: vault-app
  namespace: app
spec:
  provider: vault
  parameters:
    vaultAddress: "https://vault.example.com:8200"
    audience: app
    roleName: app
    objects: |
      - objectName: "db-password"
        secretPath: "secret/data/some/path/secret"
        secretKey: "password"

Dumped JWT (partly).

{
  "aud": [
    "app"
  ],
...
}

Proposal: make audience list, not string. so, example config would be

apiVersion: secrets-store.csi.x-k8s.io/v1
kind: SecretProviderClass
metadata:
  name: vault-app
  namespace: app
spec:
  provider: vault
  parameters:
    vaultAddress: "https://vault.example.com:8200"
    audience:
      - app
      - "https://kubernetes.default.svc"
    roleName: app
    objects: |
      - objectName: "db-password"
        secretPath: "secret/data/some/path/secret"
        secretKey: "password"

[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?

[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).