[micah_chatt]

(Disclosure: I work on Kubernetes/EKS Security at AWS)

I'm curious why they didn't look into using Kubernetes ProjectedVolumeTokens for authenticating to Vault? The tokens Kubernetes issues are not stored in etcd, and they contain pod-specific metadata so they are invalidated as soon as the pod dies (when using TokenReview). Alternatively, they can be used to directly authenticate with Vault since they're OIDC-valid tokens [1].

The semantics around secrets in Kubernetes aren't nearly as robust as Vault, so I was surprised to not see this more clearly called out (ex: list secrets == get all keys and values). Even if you use KMS/AES encryption (which they reference) that doesn't help with access control.

[1] https://www.vaultproject.io/docs/auth/jwt.html

[p10jkle]

This is on our radar and I think they can now be used directly with the kubernetes Auth plugin, although I've not heard much about it. This is a very recent change. We could have possibly got the same functionality with the jwt plugin, with some added complexity (and no tokenreview)

We don't allow read or list of secrets by any human, although of course that's not a perfect control.

[MrSaints]

Interestingly, Googling `ProjectedVolumeTokens` yields this very post. I think that says something about its maturity.

[micah_chatt]

That would by my error, its actually `BoundServiceAccountTokenVolume` and `TokenRequestProjection`