OpenBao による Kubernetes シークレット管理基盤の改善と検証

サイボウズ株式会社 後藤健太氏
2026年10月26日開催 OSSセキュリティMeetup 講演資料

Transcript

1. OpenBao による Kubernetes シークレット管理基盤の改善と検証 2026.10.26 サイボウズ株式会社 後藤 1
2. 自己紹介 • 後藤健太 • 所属 • サイボウズ株式会社 • Platform Developer eXperience (PDX) • 経歴 • 2019.04 - 2025.01 • プライベートクラウド基盤の開発 • パブリッククラウド (AWS) 基盤の運用 • 2025.02 - サイボウズ株式会社 • シークレット管理 OpenBao 導入 • Security, OpenSSF @gokken-roko • Platform Engineering 2
3. OpenSSF と サイボウズの関係 • サイボウズでは自社の基盤からアプリケーションまで幅広く OSS を活用している • Kubernetes 基盤開発の成果物の一部を OSS として公開している https://github.com/cybozu-neco • 2022 年からサイボウズは OpenSSF に General メンバーとして加盟 • OSS のセキュリティ問題への貢献 • OpenSSF の推進するセキュリティ対策の自社への導入 https://topics.cybozu.co.jp/news/2022/08/31-18229.html 3
4. 目次 01 Kubernetes のシークレットとその課題 02 OpenBao と OpenBao Agent の基本的な仕組み 03 サイボウズの OpenBao 検証における権限分離 04 デモ 05 今後の改善とまとめ 4
5. Kubernetes のシークレットとその課題 5
6. Kubernetes の通常の Secret 作成 Kubernetes でシークレットを作成しただけでは、デフォルトで暗号化ではなくエンコードされただけ Secret リソースの読み取り権限があれば、シークレットは読み取れてしまう 6
7. Kubernetes のシークレットとその課題 Kubernetes の Secret は機密データを保持するためのものだが、Secret を安全に使用することはユーザ 自身が考える必要がある 注意: KubernetesのSecretは、デフォルトでは、APIサーバーの基礎となるデータストア(etcd)に暗号化されずに保存されま す。APIにアクセスできる人は誰でもSecretを取得または変更でき、etcdにアクセスできる人も同様です。さらに、名 前空間でPodを作成する権限を持つ人は、そのアクセスを使用して、その名前空間のあらゆるSecretを読むことができ ます。これには、Deploymentを作成する能力などの間接的なアクセスも含まれます。 Secretsを安全に使用するには、以下の手順を推奨します。 • • Secretsを安全に暗号化する Secretsのデータの読み取りを制限するRBACルールの有効化または設定 • 適切な場合には、RBACなどのメカニズムを使用して、どの原則が新しいSecretの作成や既存のSecretの置き換えを 許可されるかを制限します。 https://kubernetes.io/ja/docs/concepts/configuration/secret/ 「安全な暗号化」「適切なアクセス管理」のため OpenBao が選択肢の一つとして考えられそう 7
8. OpenBao と OpenBao Agent の 基本的な仕組み 8
9. OpenBao • OpenSSF のプロジェクトの一つ • https://openssf.org/projects/openbao/ • Vault のフォーク • 機密情報、証明書、鍵などのデータを 管理するソリューション • 安全なストレージ、ローテーション、 監査ログなどの機能を提供 9
10. OpenBao による、Kubernetes Secret に依存しない仕組み Kubernetes Secret 「デフォルトで暗号化されない Secret リソースの扱い」と 「Secret リソースアクセス権限の設計」が必要 OpenBao + OpenBao Agent • Secret リソースは作成せず直接 Pod にマウント • アクセス権は ServiceAccount を元に、OpenBao 側のポリシーで制御 10
11. OpenBao と OpenBao Agent OpenBao • シークレットマネージャ • シークレットの暗号化、権限管理などを担当 OpenBao Agent • OpenBao からシークレットを取得し、ファイルに書き込む • 直接ファイルに書き込むので Kubernetes Secret は経由しない • OpenBao の API を実行するので、シークレット操作の権限は OpenBao のポリシーに従う • OpenBao Agent を Sidecar Container として注入するのは Agent Injector 11
12. OpenBao のアーキテクチャ シークレットマネージャとして、UI, API, 暗号化や認証認可の機能を提供 クライアント • 秘密情報の read / write リクエストを送る主体 • 人間(Web UI)や OpenBao Agent がアクセス主体になる サーバー • API の提供、認証・認可、秘密情報の暗号化・復号 Storage Backend • ストレージは Leader / Follower 構成で、高可用性がある 12
13. OpenBao Agent (Pod へのシークレットの注入) Pod へシークレットを注入(マウント)するのは、OpenBao Agent が担う • Pod に OpenBao Agent の Sidecar Container を設定 • OpenBao Agent が OpenBao の API を実行し認証、シークレットの取得を行う • OpenBao Agent が書き込んだファイルを、アプリのコンテナから読み込む 13
14. サイボウズの OpenBao 検証における 権限分離 14
15. マルチテナントでの権限分離 サイボウズでは、複数チームが 1 つの Kubernetes クラスタを共有するため、 「OpenBao の Namespace」と「Kubernetes の Namespace」がその境界 ユーザ(人間) • 許可された OpenBao Namespace に GitHub SSO でアクセスできる • どの Kubernetes Namespace, ServiceAccount を許可するかは、ユーザ自身が設定 Pod (OpenBao Agent) • Namespace, ServiceAccount で認証 • Kubernetes の RBAC (Pod作成などの権限管理) は引き続き必要 15
16. 各テナント内における権限管理 各テナント(OpenBao および Kubernetes の Namespace)内でも権限を管理できる ポリシーや紐づけの粒度はユーザに任されるが、柔軟な設定が可能 OpenBao 側 • シークレットのアクセスポリシーと、 許可する ServiceAccount を定義 Kubernetes 側 • ServiceAccount を アプリケーションのPodに厳密に紐づける 16
17. デモ 17
18. OpenBao のシークレットを Kubernetes の Pod で利用する OpenBao Web UI で、シンプルな Key-Value (KV) の Secret を作成し、Pod から読み込む 1. OpenBao の Web UI にアクセス 2. 読み取り専用の Policy を作成 3. Pod に割り当てる Role を作成 • 2 で作成した Policy を紐づけ 4. シークレットを作成 5. 作成したシークレットを参照する Pod を作成 6. シークレットが Pod に注入されたことを確認 7. シークレットを更新 8. シークレットの更新が Pod に反映されたことを確認 18
19. デモ: 1. OpenBao Web UI にアクセス OpenBao の Web UI は次のようになっています 19
20. デモ: 2. 読み取り専用の Policy を作成 Pod(アプリケーション側)からは、シークレットは読み取りだけで良いので、 操作を読み取り系に絞ったポリシーを作成 20
21. デモ: 3. Pod に割り当てる Role を作成 Pod (アプリケーション) が引き受けられる範囲や権限を表す Role を作成 「許可する Kubernetes の Namespace, ServiceAccount」を指定し「Policy」を紐づける 21
22. デモ: 4. シークレットを作成 Key-Value 形式でシークレットを作成 • Path: kv/app-1-secret • Key: TEST_TOKEN, Value: SuperImportantToken • Value は本来は秘匿にすべき情報 22
23. デモ: 5. 作成したシークレットを参照する Pod を作成 OpenBao の Role(kv-reader) での定義 • Kubernetes namespace の team-a を許可 • ServiceAccount の app-1-serviceaccount を許可 • kv のシークレット読み取りを許可 OpenBao で作成したシークレット • Path: kv/app-1-secret • Key: TEST_TOKEN • Value: SuperImportantToken 23
24. デモ: 6. シークレットが Pod に注入されたことを確認 • Kubernetes 上でマニフェストを apply して Pod を作成 • 5. の yaml の内容 • 作成した Pod に入り、シークレットを読み取れることを確認 • デモでは紹介していませんが、Namespace や ServiceAccount が違えば、エラーとなります 24
25. デモ: 7. シークレットを更新 Web UI から、シークレットの値を変えて、更新をする SuperImportantToken -> SuperImportantToken2 に変更 25
26. デモ: 8. シークレットの更新が Pod に反映されたことを確認 Pod に入り、Web UI でのシークレット更新が Pod に反映されたことを確認 26
27. 今後の改善とまとめ 27
28. 今後の改善 • 複数クラスタでの Secret の複製 • リージョンで分かれた Kubernetes クラスタ間で、同じシークレットを利用したい • OpenBao のインスタンスが違うと暗号化キーが違う中、安全にシークレットを共有できるか？ • 特定のシークレットのみを選択して複製できるか？ • Kubernetes 利用者に管理しやすい仕組み • セキュアなポリシーや Role を設定してもらうためのドキュメント整備 • OpenBao 自体の設定管理を IaC でするとき、OpenTofu/Terraform になるが、 Kubernetes では yaml と GitOps が使われていることからより親和性の高い手段を提供したい Kubernetes シークレットと並行運用をしながら、検証を進めていく 28
29. まとめ Kubernetes におけるシークレットの課題 • デフォルトで Secret リソースは暗号化されておらず、安全な暗号化を考える必要がある • 適切なアクセス管理も必要 OpenBao と OpenBao Agent • 安全なストレージ、アクセス管理の機能を持っている • OpenBao Agent と組み合わせることで、Pod に直接シークレットをマウントできる • OpenBao の Namespace で、複数のチームの権限を分離できる Kubernetes シークレット改善の選択肢の一つとして OpenBao が考えられる 29
30. ©️ Cybozu, Inc. 30