はじめに：理想をどうやって「現実」にするか？
こんにちは！APCのSAT室PE推進チームに所属している簗田です。
[前回（第1回）の記事]では、AKSにおけるシークレット管理の「理想の姿」を、DevEx（開発者体験）・ガバナンス・運用性の3つの観点で整理しました。
「Base64のエンコードから解放されたい！」「セキュアに、かつ自動でローテーションしたい！」という皆さんの(？）切実な願いを叶えるための"部品"として、今回ご紹介するのが 「Azure Key Vault Provider for Secrets Store CSI Driver」 です。
「名前が長いよ！」と思われた方、安心してください。私も最初はそう思いました（笑）。 でも、このツールこそが、Platform Engineering の文脈で「開発者にインフラ（シークレットの管理場所）を意識させない」ための強力な武器になるんです。
今回は、この CSI Driver が前回の3つの要件をどう解決してくれるのか、その仕組みと魅力を深掘りしていきます！
「Secrets Store CSI Driver」ってなに？
簡単に言うと、「Azure Key Vault の中身を、まるで Pod の中にあるファイル（ボリューム）のように見せかける仕組み」 です。
従来の Kubernetes Secret リソース（Base64のあれです）を介さず、外部ストアである Azure Key Vault から直接シークレットを取り出し、Pod のファイルシステムに「ガッチャンコ」とマウントしてくれます。
これがなぜ、前回の「理想」に繋がるのか。3つの要件に当てはめて解説します！
secrets-store-csi-driver.sigs.k8s.io
解決策1：【DevEx】「ファイルを読むだけ」のシンプルさ
前回の課題は、「Base64エンコードが地味に面倒」「マニフェスト管理に気を使う」ということでした。
CSI Driver を導入すると、開発者の体験は劇的に変わります。
これまで (As-Is):
echo -n "password" | base64 して、YAMLの data 欄に貼り付け。
値を更新するたびに再エンコードして kubectl apply。
これから (To-Be):
アプリケーションコードから /mnt/secrets/db-password というファイルを読み込むだけ。
「え、これだけ？」 と思うかもしれませんが、これこそが Platform Engineering が提供すべき「抽象化」の形だと私は考えています。 開発者は「値がどこから来たか（Key Vaultの認証がどうとか）」を深く知らなくても、標準的なファイルアクセスとしてシークレットを扱えるようになります。
参考:
解決策2：【Governance】「Workload ID」で最小権限を徹底
「誰がシークレットを見ていいのか？」という権限管理も、プラットフォーム側で担保すべき重要な要素です。 CSI Driver の真骨頂は、Azure の最新の認証方式である 「Microsoft Entra Workload ID」 とシームレスに連携できる点にあります。
仕組み: 特定の Pod（Service Account）に対して、Microsoft Entra Workload ID を使って Key Vault へのアクセス権（RBAC）を最小権限で紐付けます。
メリット:
Kubernetes 内部に強力な権限を持つ Secret を作らなくて済みます。
Key Vault のログで“どのIDがいつどのシークレットにアクセスしたか”を追跡できる（Pod は ServiceAccount/ID の紐付けから追跡可能）。
「プラットフォーム側が安全な道（権限）を整備し、開発者はその上を安全に走るだけ」というガバナンスの理想形が見えてきます。
参考:
Azure AD Workload ID を使用するように CSI ドライバーを構成する（Microsoft Learn）
解決策3：【Operations】運用の自動化（ローテーション）
私が学習していて「これはいい！」と感じたのが、「自動ローテーション（Auto Rotation）」です。
通常、シークレットを更新したら Pod の再起動が必要ですが、CSI Driver には「ポーリング（定期監視）」機能があります。プラットフォーム側で「2分ごとに Key Vault を見に行く」といった設定を入れておけば、セキュリティ担当者が Key Vault の値を更新するだけで、Pod 内のマウントファイルが自動的に最新化されます。
ただし、ここで一つ重要な「技術的事実」があります。 公式ドキュメントには、以下のような注意書き（NOTE）があります。
The CSI driver does not restart the application pods. It only handles updating the pod mount...
（CSI ドライバーはアプリケーション Pod を再起動しません。Pod のマウントを更新する処理のみを行います）
つまり、「ファイルの中身は新しくなるけれど、アプリがその変更を検知して読み直すかどうかは別問題」ということです。💡
「パスワードを変えたのにアプリに反映されていなかった！」という事故を防ぐためには、アプリ側で「ファイルを都度読み込む」か「変更を検知してリロードする」実装を検討する必要があります。 「便利だから導入しよう」で終わらせず、こうした一歩踏み込んだ設計指針を開発チームに提示することこそが、Platform Engineering を推進する私たちの役割だと感じました。
参考： Secret Auto Rotation (Secrets Store CSI Driver)
secrets-store-csi-driver.sigs.k8s.io
まとめ：プラットフォームエンジニアとしての視点
今回学習した「Secret Store CSI Driver」は、単なる便利ツールではありません。
開発者には「ファイルアクセス」という馴染みのあるインターフェースを提供し、
セキュリティ担当には「一元管理と完璧なログ」という安心を提供し、
運用者には「自動ローテーション」という自由を提供します。
これこそが、目指したい 「セキュアな Platform Engineering 基盤」 の重要なパーツだと感じました。
...とはいえ、「じゃあ具体的にどんな YAML を書けばいいの？」「プラットフォームチームとして、開発者にどうやってこの設定を配ればいいの？」という実戦的な疑問が湧いてきますよね。
次回は、「実戦編：SecretProviderClass をどう設計するか？」 について、具体的なマニフェストの中身に触れていきたいと思います！
ACS 事業部のご紹介
私達 ACS 事業部はクラウドネイティブ技術、Azure AI サービス、Platform Engineering などを活用し、攻めの DX 成功に向けた開発者体験の向上・内製化のご支援をしております。
また、一緒に働いていただける仲間も募集中です！
今年もまだまだ組織規模拡大中なので、ご興味持っていただけましたらぜひお声がけください。
