vault on kubernetes at cloudnative days

Transcript

1. Vault on Kubernetes ~秘匿情報の安全な管理~ March 11th, 2021 Sato Takumi Ecosystem Services Department, Technology Platforms Division Rakuten, Inc.
2. 2 ⾃⼰紹介 • 2020年4⽉ 楽天株式会社 新卒⼊社 • Applications Engineer • Platformとなるサービス群の開発、運⽤を担当 • 機械学習を利⽤した⼊社後初のPJで楽天賞を受賞 • 好きな技術︓Kubernetes, Azure, Go 佐藤 匠(さとう たくみ)
3. 3 アジェンダ • Vaultの概要 • Vaultのユースケース 1. 静的なシークレットの管理 2. 動的なシークレットの管理 3. Encryption as a Service • Vault on Kubernetes
4. 4 アジェンダ • Vaultの概要 • Vaultのユースケース 1. 静的なシークレットの管理 2. 動的なシークレットの管理 3. Encryption as a Service • Vault on Kubernetes
5. 5 Vaultとは︖ • HashiCorp社が開発したシークレットを管理、保護するためのソフトウェア ※シークレットとは認証認可を与えるものの総称でDBクレデンシャル、クラウドのIAM、トークン、 TLS証明書、ID&パスワード、SSH Keyなどを指す • クライアントサーバー⽅式 • Vaultサーバー︓シークレットの管理、保護 • クライアント︓Vaultサーバーからシークレットを取得
6. 6 アジェンダ • Vaultの概要 • Vaultのユースケース 1. 静的なシークレットの管理 2. 動的なシークレットの管理 3. Encryption as a Service • Vault on Kubernetes
7. 7 ユースケース①: 静的なシークレットの管理 ID: thisisid PW: thisispw Without Vault ID: ahfgjhg PW: gjiopaio With Vault • DBの認証情報などがハードコードされている • プライベートレポジトリで管理しても必ずしも安全 とは⾔えない。例︓公開レポジトリに誤ってpush… • シークレットをハードコードせずvaultに暗号化 した状態で管理 • 必要な時にシークレットを取得 シークレットを ハードコード シークレットを要求 コードレポジトリ App シークレットを ハードコードしない コードレポジトリ App コード ＋ シークレット コードのみ
8. 8 ユースケース②: 動的なシークレットの管理 Without Vault With Vault AWS Azure GCP DB Client ① 認証情報を要求 $ vault read <secret> ③認証情報 (期限付き) ②認証情報を⽣成 ④認証 ⑤期限が来たら 認証情報を無効 AWS Azure GCP DB Client ②保管 ③認証 ①認証情報の⽣成 社内wiki Excel • 認証情報を⻑期間使⽤→シークレットの漏洩リスク • 認証情報の使い回し→アクセス制御が難しい • 期限付きの認証情報を必要なときに発⾏ • アクセス制御が容易に⾏える • Vaultによるシークレットの⼀元管理 • シークレットへのアクセスログ
9. 9 ユースケース③: Encryption as a Service Vaultを⽤いたアプリデータの暗号化 App アプリデータ 暗号化された アプリデータ DB App Write Read 暗号化された アプリデータ 複合化された アプリデータ 暗号化された アプリデータ • キー⽣成 • キーローテーション • 再暗号化 • 暗号化ロジックを APIとして切り出すことで、アプリによらず常に⾼品質な暗号化が可能 • Vaultが暗号化キーの運⽤を⾏う。: ⽣成、ローテーション、再暗号化 • 暗号化ロジックを選択可能。︓aes256-gcm96, chacha20-poly1305, ed25519, rsa-2048, etc…
10. 10 アジェンダ • Vaultの概要 • Vaultのユースケース 1. 静的なシークレットの管理 2. 動的なシークレットの管理 3. Encryption as a Service • Vault on Kubernetes
11. 11 導⼊事例 • 問題 • 秘匿情報をKubernetesのSecretリソースで管理していたが、結局Secretマニフェストがコー ドレポジトリで管理されていた • Base64でエンコードされているだけなので、簡単にデコードされてしまう ⇨vaultで秘匿情報を管理 apiVersion: v1 kind: Secret metadata: name: mysecret type: Opaque data: username: YWRtaW4= password: MWYyZDFlMmU2N2Rm コードレポジトリ Secretマニフェスト
12. 12 システム構成 k8s Cluster A Cloud Strage k8s Cluster B Vault agent App container Load Balancer Pod Deployment Vault agent injector Statefulset Vault server inject share secret get secret Store encrypted secret
13. 13 システム構成 k8s Cluster A Cloud Strage k8s Cluster B Vault agent App container Load Balancer Pod Deployment Vault agent injector Statefulset Vault server
14. 14 Vault agent︓シークレットの取得フロー Vault K8s auth Role Secret Engine Vault agent ServiceAccountToken Vault token 認証 トークン (アクセス権限) シークレット取得
15. 15 Vault agent︓シークレットの取得フロー Vault K8s auth Role Secret Engine Vault agent ServiceAccountToken Vault token 認証 トークン (アクセス権限) シークレット取得 kubernetes auth method
16. 16 Kubernetes auth methodの設定 $ vault auth enable kubernetes $ vault write auth/kubernetes/config \ token_reviewer_jwt="$SA_JWT_TOKEN” \ kubernetes_host="https://$K8S_HOST:443" \ kubernetes_ca_cert="$SA_CA_CRT” $ vault write auth/kubernetes/role/devwebapp \ bound_service_account_names=internal-app \ bound_service_account_namespaces=default \ policies=devwebapp \ ttl=24h path "secret/data/devwebapp/config" { capabilities = ["read"] } Service Accountにアクセス権限の紐付け Vaultがkubernetes APIと通信するための設定 ※ Service Accountが有効であるか確認する ために必要
17. 17 システム構成 k8s Cluster A Cloud Strage k8s Cluster B Vault agent App container Load Balancer Pod Deployment Vault agent injector Statefulset Vault server
18. 18 Vault agent • Vault agentはSidecarとしてinjectされ、認証および、シークレットの取得を担当 • 取得したシークレットはローカルのファイルシステム経由でapp containerに共有 • Vault Clientのインストール、認証やシークレットを取得するコマンドの記述が不要 Pod シークレットの取得 App container File system Vault agent
19. 19 Vault agent︓シークレットの取得設定 apiVersion: v1 kind: Pod metadata: name: devwebapp labels: app: devwebapp annotations: vault.hashicorp.com/agent-inject: "true" vault.hashicorp.com/role: "devweb-app" vault.hashicorp.com/agent-inject-secret-credentials.txt: "secret/data/devwebapp/config" spec: serviceAccountName: internal-app containers: - name: devwebapp - image: jweissig/app:0.0.1 /app # cat /vault/secrets/credentials.txt data: map[password:salsa username:giraffe] • Annotationを追加することで、Vault agent injectorがPodにVault agentをinject • Pod内のファイルにシークレットが保存
20. 20 Vault agent︓環境変数としてシークレットを取得 annotations: vault.hashicorp.com/agent-inject: "true" vault.hashicorp.com/role: "devweb-app" vault.hashicorp.com/agent-inject-secret-credentials.txt: "secret/data/devwebapp/config" vault.hashicorp.com/agent-pre-populate-only: "true" vault.hashicorp.com/agent-inject-template-credentials.txt : | {{ with secret "secrets/data/devwebapp/config" -}} export ID="{{ .Data.data.ID }}" export PASSWORD="{{ .Data.data.PASSWORD}}" {{- end }} spec: serviceAccountName: internal-app containers: - args: [ 'sh', '-c', ‘source /vault/secrets/credentials.txt && <entrypoint script>' ] • シークレットを"export SECRET=<SECRET>" の形式でファイルに保存 • entrypointの前に、sourceコマンドを実⾏して環境変数としてセット 後述
21. 21 vault.hashicorp.com/agent-pre-populate-only: "true"の意味 • Pod起動時のシークレット取得フロー • Init container︓app container起動前にVault agentがシークレットを取得。その後Vault agentは削除 • Sidecar︓Vault agentをSidecarとしてinject。 シークレットを動的に管理 • 動的にシークレットを扱わない場合はinit containerのみで⼗分 • vault.hashicorp.com/agent-pre-populate-only: "true ”のannotationを追加することで実現 ➡Vault agentのリソースが不要に︕ Pod File system Vault agent Init container Pod App container File system Vault agent Sidecar
22. 22 まとめ • Vaultは以下のユースケースがある • 静的なシークレットの管理 • 動的なシークレットの管理 • 暗号化API • kubernetes環境からvaultを使⽤する⽅法を導⼊事例を元に紹介 • kubernetes auth method • Vault agentを⽤いてシークレットを取得
23. 23 参考⽂献 • https://docs.google.com/presentation/d/14YmrOLYirdWbDg5AwhuIEqJSrYoroQUQ8ETd6qwxe6M/edit#sli de=id.g80f1b35789_0_2545 • https://docs.google.com/presentation/d/1SFM6iKqGf7FMqQlv- UXZD2GiPu7Ae1SQiaPnMXKiPNc/edit#slide=id.g55c21e2b16_2_1600 • https://github.com/hashicorp-japan/vault-workshop-jp • https://www.vaultproject.io/ • https://www.lac.co.jp/service/product/vault.html