↓ Skip to main content
Le Site de François
  1. Index/

Secrets Store CSI Driver

Kubernetes Secrets Security Csi Storage

Secrets Store CSI Driver (formally secrets-store.csi.k8s.io) is a Kubernetes SIG Auth project that uses the Container Storage Interface to mount secrets, certificates, and keys from external secret backends directly into pod filesystems as ephemeral tmpfs volumes, bypassing the Kubernetes Secret object and etcd entirely. The driver runs as a DaemonSet on every node; when a pod referencing a CSI volume of type secrets-store.csi.k8s.io is scheduled, the driver communicates with a provider plugin over gRPC to retrieve the secret content from the configured backend, writes it to a per-pod tmpfs mount, and makes it available inside the container at the specified path. When the pod terminates, the tmpfs is unmounted and the data is gone — secrets have no persistence beyond the lifetime of the pod that requested them.

The central configuration object is the SecretProviderClass CRD, which specifies the provider to use (Vault, Azure Key Vault, AWS Secrets Manager, GCP Secret Manager), the objects to retrieve and their target filenames inside the volume, and any provider-specific authentication parameters. Each provider ships as a separate plugin installed alongside the driver. A pod requests the secrets by declaring a volume of type csi referencing the driver and a named SecretProviderClass, then mounting that volume into a container; no other changes to the pod spec are needed. By default, secrets are available only as files at the mount path. An optional sync-to-Kubernetes-Secret feature creates a native Secret object mirroring the mounted content — useful for workloads that require environment variables rather than files — but with an important caveat: the synced Secret only exists while at least one pod mounting the volume is running, and is deleted when all such pods are gone. The driver also supports periodic rotation: it re-fetches secret content from the backend on a configurable interval and updates the mounted files in place, allowing applications to detect and reload credential changes without a pod restart.

The defining advantage of the CSI driver over ESO is that secrets never enter etcd or the Kubernetes API: they flow from the external backend directly into the pod’s memory-backed filesystem, reducing the blast radius of a control-plane compromise. This matters most in environments with strict data residency or compliance requirements, or in CoCo and confidential computing deployments where minimising the trust surface of the Kubernetes control plane is a design goal. The trade-off is operational friction: the pod spec must be modified to declare the CSI volume (whereas ESO works with standard Secret references that require no pod changes), and the sync-to-Secret behaviour has the lifecycle coupling noted above. In practice, ESO and the CSI driver are deployed complementarily rather than exclusively — ESO for the broad workload base that can tolerate etcd storage, and the CSI driver for specific workloads where the stronger isolation is worth the additional configuration cost.

Related

ESO (External Secrets Operator)

Kubernetes Secrets Security Operator Gitops Cncf
External Secrets Operator (ESO) is a CNCF incubating project that bridges the gap between Kubernetes-native secrets and enterprise secret management backends. Its premise is that native Kubernetes Secrets — base64-encoded values stored in etcd — are not adequate as a primary secret store: they offer no encryption at rest by default, no access audit trail, no versioning or rotation lifecycle, and no single source of truth across multiple clusters. Rather than replacing Kubernetes Secrets as a consumption mechanism (applications still mount them as environment variables or files in the familiar way), ESO replaces etcd as their source of authority, pulling the real values from a backend that does provide those properties and keeping the Kubernetes Secret as a synchronised, ephemeral projection.

KMS v2 (Kubernetes KMS Provider v2)

Kubernetes Security Encryption Etcd Kms Secrets Key-Management
KMS v2 (Kubernetes KMS Provider version 2) is the stable (GA since Kubernetes 1.29, KMS v1 deprecated in 1.28 and disabled by default in 1.29) mechanism for encrypting the contents of the Kubernetes etcd datastore at rest using an external key management service. Without encryption, Kubernetes Secrets stored in etcd are base64-encoded — trivially decodable by anyone with read access to the etcd data files or a snapshot. With KMS v2 enabled, resources written to etcd — Secrets, ConfigMaps, and any other API objects selected by the EncryptionConfiguration — are encrypted before being persisted, using a unique per-object key derived locally. The envelope encryption scheme means those per-object keys are never stored in plaintext: only their encrypted form lives in etcd, and only the external KMS holds the wrapping key. The encryption configuration is declared in a file referenced by the API server’s --encryption-provider-config flag, with kms: apiVersion: v2 selecting the KMS v2 code path, and endpoint: unix:///path/to/plugin.sock pointing at the plugin’s Unix domain socket.

Sealed Secrets

Kubernetes Secrets Security Gitops Encryption
Sealed Secrets is a Kubernetes controller and companion CLI tool (kubeseal) created by Bitnami that solves a specific GitOps problem: how to store Kubernetes Secret manifests in a Git repository without exposing their contents. A standard Kubernetes Secret is base64-encoded, not encrypted — anyone who can read the manifest file or the Git history can decode the values instantly. Sealed Secrets resolves this by encrypting the secret values using asymmetric cryptography before they ever leave the developer’s machine, producing a SealedSecret custom resource that contains only ciphertext and is safe to commit to any repository, public or private. The corresponding plaintext Secret is materialised exclusively inside the cluster by the controller, which holds the only private key capable of decryption.