What's Next for Vault and Kubernetes

We're excited to announce multiple features that deeply integrate HashiCorp Vault with Kubernetes. This post will share the initial set of features that will be released in the coming months. The initial roadmap will focus on features that allow users with limited or no knowledge to make use of secret management capabilities including storing and accessing secrets without additional customization.

Our goal is to give a variety of options around how you can leverage Vault and Kubernetes to securely introduce secrets into your application stack. We are doing this because there is a spectrum of security and implementation details that come with each option, be that injecting secrets into a pod, secret synchronization, etc. So, we want to give you several options to choose from that best fits your applications and use cases.

»Approaching Security with Vault and Kubernetes

The most secure way to interact with Vault is for an application to directly integrate with the Vault API. Within Kubernetes, this would mean the application uses the Kubernetes service account to authenticate with Vault. However, this requires the application is written or rewritten with Vault awareness and this is not realistic for many workloads.

The features we're announcing below enable more automatic access to secrets within the context of Kubernetes. Some of these features will require more careful securing of Kubernetes itself or acceptance of windows of risk where secrets are copied through Kubernetes.

»Features

The following is the list of features that are being worked on and released in the coming months. Follow-on announcement blog posts will cover each in detail, and each item will be updated to link to that announcement post.

• Helm Chart: By using the Helm chart, you can greatly reduce the complexity of running Vault on Kubernetes, and it gives you a repeatable deployment process in less time (vs rolling your own). This feature has been released and initially supports installing and updating open-source Vault on Kubernetes in three distinct modes: single-server, highly-available, and dev mode.

• Injecting Vault secrets into Pods via a sidecar: To enable access to Vault secrets by applications that don’t have native Vault logic built-in, this feature will allow automatic injection of secrets into the pod file system for static and dynamic secrets. This will allow applications to only concern themselves with finding a secret at a filesystem path, rather than managing the auth tokens and other mechanisms for direct interaction with Vault. This feature will be made available as an option through our Helm chart. This feature has been released and supports secret injection via init and sidecar containers.

»Feedback Requested

We’re excited to discuss several feature ideas with the community to gather feedback, build support for use cases, and work towards a future release for:

• Syncer Process: We are exploring the use case of integrating Vault with the Kubernetes Secrets mechanism via a syncer process. This syncer could be used to periodically sync a subset of Vault secrets with Kubernetes so that secrets are always up-to-date for users without directly interacting with Vault. If you would like to provide feedback around this feature please comment on this GitHub issue.

• Container Storage Interface (CSI) plugin: Similar to the Vault sidecar feature (discussed above), the CSI feature will expose secrets on a volume within a pod. This will enable the injection of secrets into a running pod using a CSI plugin. If you would like to provide feedback around this feature please comment on this GitHub issue.

If you're passionate about Kubernetes, our tools, and improving those integrations, please join us! We have a few roles open for ecosystem engineers and product managers to work on Kubernetes integrations.