Consume Secrets in Kubernetes
HashiCorp Vault has an operator, sidecar container , and daemonset 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 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 of a Deployment.
The Vault Secrets Operator supports a variety of authentication methods.
Vault Agent Sidecar Injector
The Vault Agent Sidecar Injector 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 project and can be installed with the Vault Helm chart.
The Vault Agent Sidecar injector supports all authentication methods available to Vault Agent.
CSI Provider
The Vault CSI Provider 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. Functionally, a user creates a SecretProviderClass 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 and JWT 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.