Support projected ServiceAccount volumes

[dippynark]

The current implementation uses the workloads normal ServiceAccount token at /var/run/secrets/kubernetes.io/serviceaccount/token. This token does not expire and allows access to the Kubernetes API allowing Vault to impersonate the workload.

Support for projected ServiceAccount volumes would allow the token to be rotated and would mean that if the token were intercepted it could only be used to authenticate to Vault (rather than have wider impacts against the Kubernetes API).

[davidmontoyago]

Hi there, the related PR sadly went stale.

Is there currently a workaround to specify the token audience without using a projected SA volume? I'm afraid without support for a projected volume people would be forced to disable JWT issuer validation ( See: disable_iss_validation). Is this what other vault practitioners out there are doing?

I'd discourage anyone from disabling issuer validation. In GKE, when NOT using a projected volume the audience should be "" and the issuer kubernetes/serviceaccount. When using a projected volume though, the issuer changes to the https://container.googleapis.com/v1/<cluster_id>.

[dippynark]

@davidmontoyago unfortunately Kubernetes only supports custom aud field with a projected volume. I've rebased the PR again so hopefully can get it merged.

As a temporary workaround you can just not specify the audience field when creating the Kubernetes auth backend role, but this is not recommended as it allows workloads to use their 'normal' service account token for authentication to Vault. For controllers (or any workload with RBAC permissions) this would give Vault Kubernetes API Server permissions.

Issuer validation should not be impacted (different JWT field).