Vault CSI Driver: Securely Inject Secrets into Pods (Practice and Exam Guide)

Passing secrets to Pods via environment variables is easy, but it leaves risks around update propagation and persistence. The Vault CSI Driver uses the Secrets Store CSI Driver together with the Vault Provider to securely mount secrets into a Pod's tmpfs as files.

This article covers the questions operators actually wrestle with — whether to synchronize, how rotation works, and how to design permissions — while distilling the points that operations-track exams ask about most. The behavior described assumes the stable defaults documented in the official Vault docs.

Why Inject Secrets via CSI?

The Vault CSI Driver lets you mount secrets into Pods as files. Files live in the node's tmpfs and are removed when the Pod terminates, so you avoid leaving plaintext in Kubernetes' etcd.

Combining this with the Secrets Store CSI Driver's sync feature lets you replicate secrets into a Kubernetes Secret when needed. The trade-off is that plaintext now sits in etcd, so the choice depends on your operational policy.

• Rotation can be reflected without restarting the Pod (the app still needs to reload the file)
• No plaintext is kept in etcd unless you synchronize to a Kubernetes Secret
• Fine-grained permissions via ServiceAccounts and Vault's Kubernetes auth method
• File-based delivery lowers the risk of leaks via process dumps or logs compared with environment variables

Architecture and Data Flow

The Secrets Store CSI Driver's Node plugin talks to Vault through the Vault Provider. The Pod only reads files via the CSI volume — it never calls the Vault API directly. Authentication typically uses Vault's Kubernetes auth method with the Pod ServiceAccount's JWT.

A typical data flow looks like this:

• Pod ServiceAccount JWT → verified by Vault's Kubernetes auth role
• Vault issues the secret per policy
• The CSI driver on the node receives it and writes a file at the Pod's mount point
• Rotation works through the driver's periodic refresh plus the app reloading the file

Vault CSI Driver: secret injection flow into Pods

Prerequisites and Installation Essentials

Install both the Secrets Store CSI Driver core and the Vault Provider in the cluster. The Vault server must be reachable from Kubernetes and have the Kubernetes auth method enabled. On the Vault side, bind Pod ServiceAccounts to Vault roles and define the minimum policies required.

On the network side, every node needs outbound connectivity to the Vault address. The CA used to verify the certificate must be provided through Vault Provider configuration or installed in the node's trust store.

• Deploy the Secrets Store CSI Driver (e.g. install via Helm)
• Deploy the Vault Provider for the Secrets Store CSI Driver
• Vault: enable the Kubernetes auth method and create roles bound to SA names and namespaces
• Minimize Vault policy read permissions on a per-path basis
• Validate node-to-Vault TLS connectivity and certificate trust

Implementation Steps: SecretProviderClass and Pod Manifest

The SecretProviderClass declares the Vault endpoint, auth role, and the secrets to fetch. On the Pod side, you mount a CSI volume and optionally enable synchronization to a Kubernetes Secret (remember: enabling sync puts plaintext in etcd).

Below is a representative configuration. Parameter names and details vary by Vault Provider version, so always cross-check against the official documentation for the version you deploy.

• SecretProviderClass: set provider to vault, supply roleName and vaultAddress, and list target keys in objects
• Pod: reference the secrets-store.csi.k8s.io CSI driver and the SecretProviderClass name
• Only when you need sync, define secretObjects so the values are reachable via envFrom

Minimal SecretProviderClass + Pod example (YAML)

apiVersion: secrets-store.csi.x-k8s.io/v1
kind: SecretProviderClass
metadata:
  name: vault-db-creds
  namespace: app
spec:
  provider: vault
  parameters:
    vaultAddress: "https://vault.example.com"
    roleName: "app-readonly"
    # VaultのKubernetes認証メソッドのマウントパス（環境に合わせて調整）
    # vaultKubernetesMountPath: "kubernetes"
    # Vault Enterpriseで名前空間を使う場合
    # namespace: "platform/app"
    # 取得対象（objectNameはファイル名になる）
    objects: |
      - objectName: "db-username"
        secretPath: "database/creds/readonly"
        secretKey: "username"
      - objectName: "db-password"
        secretPath: "database/creds/readonly"
        secretKey: "password"
  # 同期が必要な場合のみ設定（Kubernetes Secretに複製される）
  secretObjects:
    - secretName: db-creds
      type: Opaque
      data:
        - objectName: "db-username"
          key: username
        - objectName: "db-password"
          key: password
---
apiVersion: v1
kind: Pod
metadata:
  name: app
  namespace: app
spec:
  serviceAccountName: app-sa
  containers:
    - name: web
      image: ghcr.io/example/app:1.0
      volumeMounts:
        - name: secrets-store
          mountPath: "/mnt/secrets"
          readOnly: true
      # K8s Secretへ同期した場合のみ、環境変数で参照可能
      envFrom:
        - secretRef:
            name: db-creds
  volumes:
    - name: secrets-store
      csi:
        driver: secrets-store.csi.k8s.io
        readOnly: true
        volumeAttributes:
          secretProviderClass: "vault-db-creds"

Operational Essentials: Rotation, Reload, Permissions, and Whether to Sync

Rotation rides on two wheels: the driver's refresh cycle and Vault's TTL plus role configuration. File contents can update without restarting the Pod, but nothing reaches the application unless it reloads the file. Choose a reload strategy that suits the app — signal-based reload, inotify-based watching, and so on.

Whether to synchronize to a Kubernetes Secret depends on the use case. You gain the same ergonomics as ConfigMaps and Secrets, but plaintext is now persisted in etcd. Design encryption-at-rest, RBAC, and audit logging together with that decision.

• Enabling the driver's rotation feature does not remove the need for app-side reload
• Tune file permissions to match the Pod's security context and the app user
• If you use sync, assume etcd encryption-at-rest and explicit Secret lifecycle management
• Separate Vault roles per ServiceAccount with least privilege

Exam Prep: Key Points and Pitfalls

Operations-track exams keep coming back to the same questions: where secrets are stored, who can fetch them with what permissions, and how they are updated. Being able to pick the right answer on whether to sync, on file delivery vs. environment variables, and on binding ServiceAccounts to Vault roles is what scores points.

Common failure modes include namespace mismatches between the ServiceAccount and the Vault role, insufficient Vault policies, TLS verification failures because the Vault CA was not configured, and apps that never reload the updated file.

• Direct env-var delivery is convenient but watch for update propagation and leak paths
• Enabling sync persists plaintext in etcd, so assume cluster-level encryption and tight RBAC
• Design the Pod ServiceAccount → Vault role → policy chain on least privilege at every step
• Rotation only works when both the driver and the app cooperate

Check Your Understanding

Frequently Asked Questions