Vault CSI DriverでPod内にシークレットを安全投入する実務と試験対策

Podに環境変数でシークレットを渡すのは簡単ですが、更新反映や永続化の観点でリスクが残ります。Vault CSI DriverはSecrets Store CSI DriverとVault Providerを用いて、Pod内のtmpfsにシークレットをファイルとして安全にマウントします。

本稿では、実務で迷いがちな同期の是非、ローテーション、権限設計を押さえつつ、オペレーション系の試験で頻出の論点を短時間で復習できるようにまとめます。挙動はVault公式ドキュメントに基づく安定動作を前提に説明します。

なぜCSIでシークレットを入れるのか

Vault CSI Driverを使うと、Podにシークレットをファイルとしてマウントできます。ファイルはノード上のtmpfsに置かれ、Pod終了とともに消去されるため、Kubernetesのetcdに平文を残さずに済むのが特徴です。

Secrets Store CSI Driverの「同期」機能を併用すると、必要に応じてKubernetes Secretへ複製できます。ただし、この場合はetcdに平文が残るため、運用ポリシーに応じて使い分けが必要です。

• Pod再起動なしでローテーションを反映しやすい（アプリ側の再読込が必要）
• Kubernetes Secretへ同期しない限り、etcdに平文を保持しない
• サービスアカウントとVaultのKubernetes認証で細粒度の権限管理が可能
• 環境変数ではなくファイル経由のため、プロセスダンプやログへの漏えいリスクを下げやすい

アーキテクチャとデータフロー

Secrets Store CSI DriverのNodeプラグインが、Vault Providerを介してVaultへアクセスします。PodはCSIボリュームを介してファイルを参照するだけで、直接Vault APIを呼びません。認証は通常、PodのServiceAccountのJWTを用いたVaultのKubernetes認証で行います。

以下は代表的なデータフローです。

• PodのServiceAccount JWT → VaultのKubernetes認証ロールで検証
• Vaultがポリシーに基づきシークレットを発行
• Node上のCSIドライバが受け取り、Podのマウントポイントにファイルとして配置
• ローテーションはドライバ側の周期的な更新とアプリの再読込で成立

Vault CSI DriverによるPod内シークレット投入フロー

前提条件とインストールの要点

Secrets Store CSI Driver本体とVault Providerをクラスターに導入します。VaultサーバーはKubernetesから到達可能で、Kubernetes認証メソッドが有効化済みである必要があります。Vault側では、PodのServiceAccountとVaultロールの対応付け、および必要最小限のポリシーを作成します。

ネットワーク的には、各ノードからVaultアドレスへのアウトバウンド通信が必要です。証明書の検証に使うCAは、Vault Providerの設定で渡すか、ノードの信頼ストアに配置します。

• Secrets Store CSI Driverのデプロイ（例: Helmでインストール）
• Vault Provider for Secrets Store CSI Driverのデプロイ
• Vault: Kubernetes認証メソッドの有効化とロール作成（SA名・ネームスペースをバインド）
• Vaultポリシーで読み取り許可を最小化（パス単位）
• ノード→Vault間のTLS疎通と証明書検証の整備

実装ステップ: SecretProviderClassとPodマニフェスト

SecretProviderClassでVaultへの到達情報、認証ロール、取得対象のシークレットを記述します。Pod側ではCSIボリュームをマウントし、必要に応じてKubernetes Secretへの同期を有効化します（同期を有効にするとetcdに保存される点に注意）。

以下は代表的な設定例です。実際のパラメータ名や詳細はVault Providerのバージョンにより差分があるため、導入時は公式ドキュメントの該当バージョンを参照してください。

• SecretProviderClass: providerにvaultを指定、roleNameとvaultAddress、objectsで対象キーを列挙
• Pod: CSIドライバsecrets-store.csi.k8s.ioを指定し、secretProviderClass名を参照
• 同期が必要な場合のみsecretObjectsを定義し、envFromで参照可能にする

SecretProviderClassとPodの最小構成例（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"

運用の勘所: ローテーション・再読込・権限と同期の是非

ローテーションはドライバの更新サイクルとVault側の有効期限・ロール設定の両輪で成立します。Podを落とさずファイル内容を更新できる一方、アプリ側がファイル再読込を実装していないと反映されません。シグナルによる再読込やinotifyでの監視など、アプリ特性に合わせた再読込戦略を用意しましょう。

Kubernetes Secretへの同期はユースケース次第です。ConfigMap/Secretと同じ操作性を得られますが、etcdに平文が保存されます。クラスターの暗号化設定、RBAC、監査ログなどを合わせて設計しましょう。

• ドライバのローテーション機能を有効化しても、アプリの再読込は別途必要
• ファイル権限はPodのセキュリティコンテキストやアプリユーザーに合わせて調整
• 同期を使う場合はetcd暗号化とSecretのライフサイクル管理を前提にする
• VaultロールはServiceAccountごとに最小権限で分離

試験対策: 押さえるべき要点と落とし穴

オペレーション系の試験では、シークレットがどこに保存され、どの権限で誰が取得でき、どう更新されるかが頻出です。特に「同期の是非」「環境変数ではなくファイル提供」「ServiceAccountとVaultロールのひも付け」を正しく選択できるかがポイントです。

トラブル事例としては、ServiceAccountとVaultロールのネームスペース不一致、Vaultのポリシー不足、VaultのCA未設定によるTLS検証失敗、アプリがファイル更新を再読込しない、などがあります。

• 環境変数直渡しは便利だが更新反映と漏えい経路に注意
• 同期を有効にするとetcdに平文が残るため、クラスタ暗号化とRBACを前提化
• PodのServiceAccount→Vaultロール→ポリシーの鎖を常に最小権限で設計
• ローテーションはドライバとアプリの双方で成り立つ

問題で確認

よくある質問