Consume Secrets in Kubernetes
HashiCorp Vault has an operator(opens in new tab), sidecar container(opens in new tab) , and daemonset(opens in new tab) options available to provide flexible consumption of secrets in Kubernetes environments. Each of these provide different features, and advantages and disadvantages depending on how the Platform Team manages Kubernetes within the organization.
Vault Secrets Operator (VSO)
The Vault Secrets Operator(opens in new tab) manages secrets on Kubernetes using Vault. The primary utility of the Operator lies in its ability to facilitate the consumption of secrets as native Kubernetes secrets. The Operator renders secrets natively as Kubernetes Secrets. The Operator also provides full secrets lifecycle management, including static and dynamic secrets from the Vault server. The Operator is also capable of managing the rotation of secrets, and notifying applications via rolling updates(opens in new tab) of a Deployment(opens in new tab).
The Vault Secrets Operator supports a variety of authentication methods(opens in new tab).
Vault Agent Sidecar Injector
The Vault Agent Sidecar Injector(opens in new tab) is designed to inject Vault secrets into your applications without requiring the applications to interact with Vault directly. The Agent Sidecar Injector accomplishes this by rendering Vault secrets to shared memory volumes. This approach offers remarkable convenience by allowing containers within a pod to consume secrets without being made Vault-aware. The Vault Agent sidecar Injector functions as a Kubernetes mutating webhook service, intercepting pod events and injecting Vault Agent container(s) into the pod if specific annotations exist on the resource. The Vault Agent Sidecar Injector is a part of the vault-k8s(opens in new tab) project and can be installed with the Vault Helm chart(opens in new tab).
The Vault Agent Sidecar injector supports all authentication methods(opens in new tab) available to Vault Agent.
CSI Provider
The Vault CSI Provider(opens in new tab) provides secrets to applications running within Kubernetes, operating as a daemonset as opposed to a sidecar within each pod. The CSI Provider utilizes standard Kubernetes CSI Secrets Store volumes(opens in new tab). Functionally, a user creates a SecretProviderClass(opens in new tab) object which specifies vault as the secret provider and contains the auth details and secrets to retrieve from Vault. When a Pod is created that references that SecretProviderClass, the Vault CSI provider uses that information along with the pod's service account to retrieve and mount secrets into the pod's CSI volume." This is a blocking operation, as secrets must be retrieved and populated during the ContainerCreation phase, so a pod will not start until the secret has been read and written to the volume.
The CSI Provider supports Kubernetes(opens in new tab) and JWT(opens in new tab) authentication methods.
Usage Scenarios
Scenario 1
The platform team manages an application on an edge appliance that demands substantial uptime. This application is capable of reading secrets from a CSI volume and can fetch updates without necessitating a pod restart. After evaluating the available options, a sidecar proves to be too resource intensive, and the appliance does not contain multiple Kubernetes nodes so a rolling update is not an option. Ultimately the team settles on the CSI driver for the ability to keep their application up when secrets are updated.
Scenario 2
A platform team wants to leverage multiple Vault instances, and requires the ability to connect to multiple namespaces to retrieve secrets for their applications. They also need to leverage their AWS credentials to authenticate to Vault. The team decides quickly on VSO for its ability to render as native Kubernetes secrets, perform rolling updates, and leverage AWS credentials.
Additional References
- Kubernetes Vault integration via Sidecar Agent Injector vs. Vault Secrets Operator vs. CSI provider(opens in new tab)
- VSO Announcement Blog(opens in new tab)
- Kubernetes documentation about Rolling Updates(opens in new tab)
- Sidecars and DaemonSets: Battle of containerization patterns(opens in new tab)