EKSシークレット管理のつらみと責務分解

Transcript

1. EKSシークレット管理のつらみと責務分解 じぇまき ギフティ / GX Platform Engineering チーム コンテナ基盤リアルトーク〜コンテナ運用のつらみ大集合〜 / 2025.3.261
2. 自己紹介 牧 純平 (@j-maki) ギフティ株式会社 GX Platform Engineering チーム EKS基盤の構築・運用やらを担当 2
3. 会社紹介 3
4. 今日話すこと 1. 元々のEKSでのシークレット管理で辛かった点 2. ESOを導入して、PEとアプリチームの責務をどう分けたか 3. 「きれいに二分できない」リアルな責務分解の話 4
5. 前提 - EKSとシークレット ECS の場合 → タスク定義で Secrets Manager を直接参照できる EKS の場合 → Secrets Manager の値をクラスター内に直接持ち込めない → 何かしらの仕組みが必要 5
6. Before - Terraformで一元管理していたが… 構成 Secrets Manager のリソース定義から EKS上のSecretまで すべてTerraformモジュ ールで一律生成 運用のつらみ 初回はダミー値を投入 → アプリチームが本物の値を発行して再度PE側で terraform apply シークレットの追加・変更のたびに PEへの依頼が必要 アプリチームが自律的にシークレットを管理できない → PEがボトルネックになっていた 6
7. やりたかったこと アプリチームが自分のシークレットを自律的に管理できるようにしたい PEはインフラ基盤の整備に集中したい → 責務分解が必要 → External Secrets Operator (ESO) に移行 7
8. なぜESOか - EKSシークレット同期方式の比較 CSI Driver (ASCP) ESO 提供元 AWS公式 OSS (CNCF) 仕組み Pod起動時にボリュームマウント Podと独立して定期同期 K8s Secret生成 オプション（追加設定要） ネイティブに生成 CSI Driver は Podのライフサイクルに密結合 → PE/アプリ間の分業が難しい印象 ESO は K8s Secretを生成するだけのシンプルな仕組み → 今回の責務分解の目的に合いそうなESOを選定 8
9. ESOの全体像 9
10. 責務分解の判断軸 値の所有者 = 管理者にすべき このシンプルな原則で、各リソースの責務を整理していった そのシークレットの値を知っている / 知るべきなのは誰か？ “ “ 10
11. Secrets Manager の責務分解 リソース定義（箱）は常にPE。値の管理者はシークレットの性質で変わる。 対象 リソース定義（箱） 値 PE作成（DB, NewRelic等） PE PE アプリ固有（外部サービスのAPIキー等） PE アプリ 判断軸：「その値を知っているのは誰か」 PEが作成するもの → PEがTerraformで管理 アプリ固有の秘匿情報 → アプリチームがAWSコンソールから変更 11
12. IAMポリシーの管理 IAMポリシーは Secrets Managerのリソース（ARN）単位でアクセス制御している 箱（リソース）が同じなら、中の値を変更しても IAMポリシーの変更は不要 → PEへの依頼なしにシークレットを更新してもらう 12
13. ESOリソースの責務 - Namespaceで責務が変わる 13
14. After - どうなったか アプリチームがAWSコンソールから自分で値を変更できるようになった PEへの依頼が減った PEはインフラ基盤の整備に集中できるようになった 14
15. まとめ 1. 「ツール選定」より「責務設計」が難しい 2. 責務分解は一律ではなく、Namespaceの性質（値の所有者）で決めた 3. 今回の判断軸は 「そのシークレットの値を知っているのは誰か？」 15
16. ご清聴ありがとうございました! 16