Vault, Kubernetes, and the Graduation of vault-k8s to Version 1.0

Kubernetes has become the de facto orchestrator for all manner of workloads and enterprises large and small are adopting Kubernetes across their fleet of applications and services. Using HashiCorp Vault, practitioners are able to augment the security model of their secrets in Kubernetes clusters. The Vault team has a long history of working with the Kubernetes community to create great integrations that allow users to deploy Vault on their Kubernetes clusters or consume secrets for their apps running in Kubernetes from an external Vault.

Adding to that long history, we are pleased to announce the graduation of vault-k8s to version 1.0, signifying an important milestone for the project.

»A Brief History of Vault and Kubernetes

As you can see, the Vault team has made tremendous strides in integrating Vault into Kubernetes. Over the years, for example, we have introduced:

• Multiple Helm charts that allow you to get Vault up and running in Kubernetes.
• The vault-k8s mutating admissions controller, which can inject a Vault agent as a sidecar and fetch secrets from Vault using standard Kubernetes annotations.
• The Vault CSI secrets provider, which graduated to version 1.0 in January of 2022. By leveraging the Vault CSI secrets provider in conjunction with the CSI driver, Vault can render Vault secrets as Kubernetes secrets for a more native user experience.

For differences between the injector model and CSI secrets provider please refer to the Vault documentation (Agent Injector vs Vault CSI Provider) and relevant blog posts (Retrieve HashiCorp Vault Secrets with Kubernetes CSI).

This year we introduced another method for Kubernetes interaction, the Kubernetes secrets engine.

»The Kubernetes Secrets Engine

With Vault 1.11 (released June 2022), we introduced a new secrets engine that allows an authenticated application or user to request short-lived, dynamically generated Kubernetes service account tokens. It can also optionally create service accounts, roles, and role bindings. The new service account tokens have a configurable TTL and any objects created are automatically deleted when the Vault lease expires.

Diagram: Kubernetes secrets engine workflow. A Jenkins runner requests cluster access for a kubernetes service account.

The Kubernetes secrets engine aims to provide just-in-time secure access to Kubernetes clusters without needing to manually generate service-account tokens that can be long lived. Applications such as CI/CD tools or even human users can leverage the Kubernetes secrets engine to get secure access to Kubernetes clusters while following proper role-based access controls (RBACs) and the principle of least privilege.

»vault-k8s Grows Up

The vault-k8s mutating admissions webhook has been deployed at high scale by both large enterprise customers and open source practitioners. Using a mutating webhook and standard pod annotations, vault-k8s injects a sidecar that retrieves secrets from Vault and makes it available to application pods.

Diagram: vault-k8s sidecar injection workflow.

The vault-k8s admissions controller is one of the most popular projects the Vault team has released, with more than 500 GitHub stars and its also one of the biggest drivers for EKS clusters consuming secrets from HCP Vault (HashiCorp’s managed Vault offering).

Given the maturity of the project, we are happy to announce that vault-k8s is now 1.0.

This gives the project more stability in terms of APIs and backwards compatibility.

»The Future of vault-k8s

As you read this blog post, you may be wondering how else we can improve the integration between Vault and Kubernetes? The team is continually adding new features to all the projects mentioned above, and we are actively engaged with the community looking for feedback. But we still believe that we can do more to meet our practitioners where they are in their Kubernetes journey. Whether that means providing an even more native experience for applications consuming secrets (Vault secrets as Kubernetes secrets) from Vault or helping practitioners who want to run Vault on Kubernetes, the team is iterating on several ideas including CRDs for secrets engines, authentication methods, and more.

TL;DR: We are not done yet — please stay tuned.

»A Big Thank You to the Practitioner Community

Finally, none of this would have been possible without the tremendous support of the Vault engineering team, the HashiCorp developer advocates, and HashiCorp co-founders Armon Dadgar and Mitchell Hashimoto. But as usual, many of the most important contributions have come from the practitioner community. Thank you and keep those pull requests coming.