First, thanks for taking the time to offer feedback regarding what we call "secrets" in Kubernetes. As you've rightfully pointed out the current implementation of "secrets" are stored unencrypted in etcd; something like Hashicorp's Vault [1] would be a much better choice for the given use-case.

I've already began exploring how an integration between Vault and Kubernetes would work [2]. There are some things to work out, but those discussions are under way [3]. The current prototype/example demonstrates one way of leveraging Vault from applications deployed on Kubernetes, without changes to the Kubernetes core.

While the vault-controller [2] works, we can do better. One idea is to consider what a deeper Vault integration looks like. Ideally we can modify parts of Kubernetes, mainly the kubelet agent that runs on every node, to handled the secure generation and renewal of unique Vault tokens for each Pod during the Pod creation phase.

Another idea would be to rethink "secrets" altogether and rebuild the entire feature on top of the Vault API. We can "hide" Vault under the current "secrets" API, which would let us remain backwards compatible. That would be phase one. Phase two could introduce new Secret extensions, which would enable users to declaratively manage Vault tokens, backends, and secret renewals through the Kubernetes API.

[1] https://www.vaultproject.io

[2] https://github.com/kelseyhightower/vault-controller

[3] https://github.com/kubernetes/kubernetes/issues/10439#issuec...