We created the Azure Key Vault to Kubernetes project as a way for us in Sparebanken Vest (Norwegian bank) to handle Azure Key Vault secrets securely in Kubernetes. It made perfect sense to us to open-source this project, as it is not our core business. Hopefully others can find it useful too.

Azure Key Vault to Kubernetes has two components that can be installed and run in the same cluster, or installed as single entities:

Azure Key Vault Controller —synchronize Azure Key Vault secrets into native Kubernetes secrets, and keeps them updated

Azure Key Vault Env Injector — transparently inject Azure Key Vault Secrets into applications running in Kubernetes containers, without revealing its content to Kubernetes resources, Etcd or its users

The recommendation is to have both installed, enabling native Kubernetes secrets when needed and transparently injecting environment variables for all other cases.

Another recommendation is to have a dedicated Azure Key Vault per Kubernetes cluster, and to store all secrets there and not in Kubernetes.

Authentication and Authorization

Having a dedicated Azure Key Vault per Kubernetes cluster also aligns with how authentication works with Azure Key Vault. By default it uses the same Service Principal that Kubernetes use when provisioning resources in Azure, like Load Balancers and VM’s. Explicit authorization for Azure Key Vault must still be configured before the components will be able to access secrets. For details and other options for authentication, see the project documentation.

Why not use Azure Key Vault directly from the Application?

It is definitely possible and unfortunately quite common. The downside is a direct dependency to Azure Key Vault from the application, which locks the application to an environment where Azure Key Vault is available.

Adhering to the 12 Factor App, secrets is config, and should be injected into applications using environment variables. They are a language- and OS-agnostic standard. (ref 12 Factor App: https://12factor.net/config)