1. はじめに：AKSのシークレット管理を考えてみました!
はじめまして！
APCのSAT室PE推進チームに所属している簗田です。
突然ですが、皆さんはAKS (Azure Kubernetes Service) 上のアプリケーションで、データベースのパスワードやAPIキーといった「シークレット（機密情報）」をどう管理していますか？
Kubernetes標準の Secret（Base64エンコード）をそのまま使っていますか？ それとも、何か別の仕組みを導入していますか？
私の所属するSAT室は、Platform Engineering を推進し、お客様の開発チームが「自走（内製化）」できるような基盤づくりを支援することをミッションとしています。
私自身も、その一環として「どうすれば開発者体験 (DevEx) とセキュリティを両立できるか？」をテーマに、AKSプラットフォームの"部品"となる技術を日々学習・評価しています。
その中で、まず最初にぶつかる大きなテーマの一つが、この「シークレット管理」だと感じています。
この記事は、私と同じように
- 「Secret のBase64エンコードって、正直ちょっと不安...」
- 「開発者にセキュリティを丸投げせず、プラットフォーム側でうまく隠蔽したい」
- 「Azure Key Vaultと連携する『イケてる』方法が知りたい！」
と悩んでいる方に向けて、私が有力候補として「Secret Store CSI Driver」というコンポーネントを調査し、「Platform Engineering の部品としてふさわしいか？」という観点で評価したプロセスを共有するものです。
参考: > - Kubernetes Secrets 公式ドキュメント
- Azure Key Vault 公式ドキュメント
- Secret Store CSI Driver 公式ドキュメント
- AKS でのシークレット管理のベストプラクティス（Microsoft Learn）
（⚠️注意点⚠️ まだチームとして固まった公式見解ではなく、あくまで私の現時点での学習メモ・考察になりますが、同じ悩みを持つ誰かの参考になれば嬉しいです！ ）
2. 私が考える「理想のシークレット管理」の要件
1章でも書いたように、私の所属するSAT室は「お客様の内製化支援」をミッションに Platform Engineering 推進に取り組んでいます。
そのミッションを達成するために、私自身が「理想のAKSプラットフォームとは何か？」を考えたとき、Kubernetes標準の Secret は、いくつかの課題があるなあとなんとなく思っていました。
そこで、今回の調査（学習）にあたって、私が「ここは大事なのでは」と考える評価軸（要件）を、3つの観点で整理してみました。 （あくまで私の現時点での考察です！）
要件1: 開発者体験 (DevEx) - 圧倒的に楽であること
「内製化」で大事なことの一つとして、開発者に「喜んで使ってもらう」ことだと考えています。
現状の課題 (As-Is): 開発者が kubectl create secret コマンドやマニフェストで Secret リソースを直接管理する必要がある。
特に、値はBase64エンコード必須。これが地味に面倒で、私はよくエンコード・デコードを間違えそうになります...（ヒューマンエラーの元ですよね）
アプリケーション側も、Secret を環境変数やVolumeとしてマウントする定義をPod側に書く必要があり、Kubernetesのお作法を覚える負担があったりします。
参考: > - Kubernetes Secrets の作成と利用方法（公式）
目指す理想 (To-Be): 開発者は Secret リソースやBase64を一切意識しなくてよい。
アプリケーションは、コンテナ内の特定のファイルパス（例: /secrets/db-password）を読むだけで、シークレットにアクセスできる。
開発者は「どのKey Vaultのどのシークレットか」といったインフラの詳細を知らなくてよい（＝プラットフォーム側がうまいこと隠蔽する）。
要件2: ガバナンス (Security) - 意識せずとも安全であること
開発者に「楽」を提供するだけでなく、プラットフォームとして「安全」を担保する必要はあるかと思います。
現状の課題 (As-Is): Secret リソースは、etcd内では暗号化されていますが、権限があれば kubectl get secret ... -o yaml で簡単にBase64デコードして中身を見れてしまいます。
「誰が」「いつ」そのシークレットにアクセスしたかの監査証跡（Audit Log）を追うのが難しいと感じます。
参考: > - Kubernetes Secrets のセキュリティに関する注意点（公式）
- Azure Key Vault の監査ログ（公式）
目指す理想 (To-Be): シークレットの実体は、Azure Key Vaultのような堅牢な外部ストアで一元管理される。
Key Vault側の機能で、アクセスログ（監査証跡）が確実に取得できる。
プラットフォーム側（私のような運用者）が、「どのアプリケーション（Pod）が」「どのシークレットに」アクセスできるかを集中管理できる。
要件3: 運用性 (Operations) - 持続可能であること
最後に、その仕組みが「持続可能」であることも重要です。これは開発者と、私のようなプラットフォーム運用者の両方にとっての運用性です。
現状の課題 (As-Is): セキュリティポリシーで「パスワードを90日ごとに変更」といったルールがあった場合、手動で Secret リソースを更新し、それを利用するPodを再起動するのは非常に大変です。私なら絶対どこかで更新漏れを起こしそうです。
目指す理想 (To-Be): Key Vault側でシークレットの値が更新されたら、コンテナ内のファイルも自動的に更新（ローテーション）される。
これにより、開発者もプラットフォーム運用者も、面倒なローテーション作業から解放される。
参考: >- Azure Key Vault Provider for Secrets Store CSI Driver のローテーション機能
- Azure Key Vault のキー、シークレット、証明書のローテーション
これら3つの要件を両立させることが、「内製化支援」に繋がるプラットフォームの第一歩だと考えました。
この「理想の要件」をものさしとして、次の章から「Secret Store CSI Driver」がこれをどう満たしてくれそうか、学習した内容をまとめていきます。
# ACS 事業部のご紹介
私達 ACS 事業部はクラウドネイティブ技術、Azure AI サービス、Platform Engineering などを活用し、攻めの DX 成功に向けた開発者体験の向上・内製化のご支援をしております。
www.ap-com.co.jp
www.ap-com.co.jp
また、一緒に働いていただける仲間も募集中です！
今年もまだまだ組織規模拡大中なので、ご興味持っていただけましたらぜひお声がけください。
www.ap-com.co.jp
