How does the Secrets Store CSI Driver deliver external secrets into a Kubernetes Pod, and what does a SecretProviderClass's secretObjects field add?

## What the driver is The **Container Storage Interface (CSI)** is Kubernetes' plugin interface for volumes. The **Secrets Store CSI Driver** uses it for something other than disks: it presents secrets from an external secret manager as **files in a Pod's volume**. It runs as a **DaemonSet** on every node, next to a **provider plugin** for each backend. The driver handles the Kubernetes side, and the provider knows how to talk to one particular secret manager. ## The pieces - **`SecretProviderClass`** (API group `secrets-store.csi.x-k8s.io`, version `v1`) is namespaced. It contains: - `spec.provider`, which names the provider plugin; - `spec.parameters`, a free-form string map that only the provider interprets (which objects to fetch, which role to use); - `spec.secretObjects`, which optionally mirrors the fetched objects into Kubernetes Secrets. - **The Pod's volume** is an inline `csi` volume with `driver: secrets-store.csi.k8s.io`, `readOnly: true` and `volumeAttributes.secretProviderClass: <name>`. - **`SecretProviderClassPodStatus`** is an internal object the driver writes to record which Pod mounted which class and which object versions it received. ## Mount-time flow 1. The scheduler places the Pod, and the kubelet on that node asks the CSI driver to publish the volume. 2. The driver looks up the `SecretProviderClass` in the Pod's namespace. 3. It calls the provider over a local socket with the parameters and the Pod's identity, typically the Pod's ServiceAccount token, so access can be scoped per workload. 4. The provider fetches the secrets and returns their contents. 5. The driver writes them as files into a tmpfs-backed mount. The container starts and reads them from its `mountPath`. The secret is fetched **at Pod start**. If the provider is unreachable, the mount fails and the Pod stays in `ContainerCreating`, with mount errors in its events. That is a real difference from the External Secrets Operator, where a Secret already exists before the Pod is scheduled. ## secretObjects: syncing to a Kubernetes Secret Some consumers cannot read files: an env var, an Ingress TLS reference, an `imagePullSecrets` entry. For those, `secretObjects` tells the driver to also create a Secret: - `secretName` and `type` (for example `Opaque` or `kubernetes.io/tls`); - `data[]`, where each entry maps an `objectName` (a mounted object) to a `key` in the Secret; - optional `labels` and `annotations`. The caveats are what interviewers look for: - **Sync happens only after a mount.** The Secret is created when a Pod mounts the volume. A Deployment that only uses `secretKeyRef` and never mounts the CSI volume will wait forever for a Secret that never appears. - **Lifetime follows the consumers.** The driver sets owner references from the mounting Pods' owners (for example their ReplicaSet), so the Secret is garbage-collected once nothing that mounts it remains. - **It needs extra RBAC.** The driver must be allowed to write Secrets. The Helm chart gates that behind `syncSecret.enabled`, which is `false` by default. ## Rotation | Driver setting | Default | Effect | |---|---|---| | `--enable-secret-rotation` | `false` | Periodically re-fetches and rewrites the mounted files | | `--rotation-poll-interval` | `2m` | How often that re-fetch runs when rotation is on | With rotation on, the **files** in running Pods are updated, and a synced Secret is updated too. Environment variables built from that Secret still do not change in a running container. The driver's own flag help still labels rotation alpha. ## CSI driver compared with the External Secrets Operator | Aspect | Secrets Store CSI Driver | External Secrets Operator | |---|---|---| | Where values land | Files in the Pod (Secret optional) | A Kubernetes Secret, always | | When they are fetched | At Pod mount, then per poll if rotation is on | On a timer, independent of Pods | | Provider outage at Pod start | New Pods fail to start | New Pods start with the last synced Secret | | Values in etcd | Not unless `secretObjects` is used | Yes, as a Secret | | Runs as | Node DaemonSet plus provider plugins | One cluster controller | Teams that do not want secret values in etcd at all prefer the file-only CSI path. Teams that want Pods to start even during a secret-manager outage prefer ESO.