As the @Rico mentioned exposing the secrets both in Vault and in Kubernetes defeats the purpose of using Vault in the first place.

With Vault, data is encrypted (transit/rest), and you can provide an access grained control over who can access what data. Exposing the data inside Vault to a Kubernetes Secret object which is basically limited to base64 encoding, will largely defeat the greatest benefit of Vault, which is to secure your Infrastructure and being the single entity responsible for managing your secrets.

Vault is an awesome tool, but in my perception it can get quite more complex for non-dev configurations, since you are going to have to attach the likes of Consul so you can have a persistent backend storage, therefore utilizing an architectural distributed pattern such as the sidecar pattern might also be extremely overkill and not recommended at all.

• But with it you could have a vault instance "living" in the same Pod as your "main" container, therefore leveraging the encryption service provided by Vault, but we would be tying the lifecycle of Vault to the lifecycle of the Pod.
• With this approach we would be required to have a Vault instance on each Pod, in case we plan on having to access secret information, which will just make the system extremely more complex. With this approach we could separate the secret information required for each object on multiple vault instances and therefore spreading the secret information of our infrastructure to multiple places, but we keep on increasing the challenge of managing our infrastructure.

So I definitely understand that trying to find a way to have the secret information required for a Pod right next to it might seem tempting, specially in a simple manner, but it would definitely defeat the purpose if it is just left completely unencrypted.

With this out of the way, why not simply create a Vault controller which will be the entity responsible to interact with Vault and whose is going to be responsible for querying Vault for Wrapped Tokens, which can temporarily give access to certain secret information, after being unwrapped by an init container inside the Pod? Is that due to the extra time required for starting up a Pod, since we need to perform some early calls in order to retrieve an Wrapped Token? Or is ut due to the extra latency of having to perform extra calls whenever it is necessary to query secret data from Vault?

Whenever I think about the idea of integrating Kubernetes and Vault, I generally tend to think about the following prototype created by Kelsey Hightower explained here.