HashiCorp Vault Provider needs to identify to Vault as the pod it is servicing.

[james-atwill-hs]

The introduction of Vault ( #23 ) uses the permissions associated inside where the driver is running to authenticate to Vault (and therefore will likely have a superset of policies to serve up secrets).

Currently pods use ServiceAccounts as identity. Vault will consume the serialized form of the ServiceAccount for authentication. This makes it easy for pods to authenticate, but comes with issue that Vault could use that ServiceAccount token to masquerade as the service in question. Realistically this is an acceptable tradeoff.

In order for the Vault CSI driver to identify as a pod to Vault, it needs access to its ServiceAccount; but now the risk surface increases quite substantially.

Bound ServiceAccounts are currently under discussion ( Proposal: https://github.com/kubernetes/community/blob/master/contributors/design-proposals/auth/bound-service-account-tokens.md Blog Post: https://thenewstack.io/no-more-forever-tokens-changes-in-identity-management-for-kubernetes/ ), this would be an ideal use case for them.

The current mechanism where people use init/sidecar containers to manage Vault secrets keeps the ServiceAccount inside the pod other than when authenticating.

also: hashicorp/vault#7365

(cc: @anubhavmishra @ritazh )

[anubhavmishra]

@james-atwill-hs Thanks for creating the issue!

[ritazh]

Closing in favor of hashicorp/vault-csi-provider#16