Vault + EKS + AWS SSOで実現する秘密情報管理

Vault + EKS + AWS SSOで実現する秘密情報管理

1. Vault + EKS + AWS SSOで実現する秘密情報管理 CloudNative Days Tokyo 2020
2. 自己紹介 後藤 健汰（gotoken） @kennygt51 • SIerでの運用系SEを経て、 2019年1月 マネーフォワード入社 • インフラエンジニア • アプリケーションのコンテナ化、サービ スのAWS移行
3. 今日話すこと なぜVaultを選んだのか？ アクセスコントロール Kubernetes（EKS）における秘密情報管理 AWS移行プロジェクト マネーフォワードについて これから まとめ
4. マネーフォワードについて
5. すべての人生を、 便利で豊かにする。 ビジネスの成長を加速させる。 くらしの経済メディア お金の見える化サービス 金融商品の比較・申し込みサイト 自動貯金アプリ お金を前へ。人生をもっと前へ。 パートナーと共に、 新たな金融サービスを創出する。 お金をいい方向へと動かす。 for ◦◦ 金融機関お客様向け自動家計簿・ 資産管理サービス 通帳アプリ 金融機関お客様向け通帳アプリ MF Unit 金融機関のアプリへの一部機能提供 企業間後払い決済サービス 売掛金早期資金化サービス BFM 法人向け資金管理サービス 成長企業向けフィナンシャル・ アドバイザリーサービス バックオフィス向け業務効率化ソリューション マネーフォワード MEユーザーのための FP相談窓口 マネーフォワード MEのデータを分析し最 適な行動をアドバイス DX人材特化のキャリア支援サービス
6. AWS移行プロジェクト
7. AWS移行プロジェクト • 2012 年の創業当初からオンプレミス＠北海道 ◦ 物理サーバーを購入し、インフラ担当者がセットアップし運用 • 2018年下旬頃より、AWS移行プロジェクトが発足 ◦ オンプレミスで稼働するサービスの漸進的マイグレーション • 2020年9月現在、複数サービスがAWS上で本番稼働中
8. マルチテナントEKS及びマルチアカウントアーキテクチャ • マルチテナントEKS及びマルチアカウントアーキテクチャを採用 • オンプレミス環境で稼働するサービスの移行及び新規サービスの受入を行ってい る 詳細については 弊社のエンジニアが登壇する 　　AWS Summit Online をチェック！
9. Kubernetes（EKS）における 秘密情報管理
10. Kubernetes（EKS）における秘密情報管理 Kubernetes（EKS）クラスタで扱う秘密情報どう管理するか？ • どこに 秘密情報を保存するのか？（可用性を担保） • どのように アプリケーションから利用するのか？ • だれが 秘密情報を管理（追加/変更/削除）するのか
11. Kubernetes（EKS）で利用する秘密情報管理の仕組み Kubernetes（EKS）で利用する秘密情報をする仕組みの一例 ・KubernetesのSecretsリソース ・Sealed Secrets ・AWS Secrets Manager ・HashiCorp Vault
12. HashiCorp Vaultとは何か HashiCorp Vaultとは HashiCorp社が開発したOSS 秘密情報を管理・保護する為のソフトウェア 特徴 • 秘密情報の保存先は拡張性が高く、様々なコンポーネントから選択可能（ Storage Backend） • 様々な秘密情報を管理できる（ Secret Engine） • IdentityにPolicyを割り当てることで柔軟な認可の制御ができる（ Auth Method） • 認証により発行された Tokenは時間ベースでRevokeされる（Client Token）
13. なぜVaultを選んだのか？
14. 実現したかったこと 実現したい要求の中で、特に以下の3点を重視 1. 管理対象の秘密情報の量が多い 2. 特定の秘密情報は、アプリケーション間で共有する必要がある 3. 秘密情報管理をサービス開発者に権限移譲していきたい 上記の3つの要求を実現可能であることからVaultを採用
15. 管理対象の秘密情報の量が多い 1. 管理対象の秘密情報の量が多い 2. 特定の秘密情報は、アプリケーション間で共有する必要がある 3. 秘密情報管理をサービス開発者に権限移譲していきたい
16. 管理対象の秘密情報の量が多い • マネーフォワードは多くのサービスを提供している • そのため、管理すべき秘密情報はかなりの量になる • 大量の情報を、効率的に管理したかった
17. 管理対象の秘密情報の量が多い 実現方式 • パスベースで、Key-Value形式の秘密情報を管理 ◦ KV Secrets Engineを有効化 • 使いやすいWeb UI
18. 特定の秘密情報は、アプリケーション間で共有する必要がある 1. 管理対象の秘密情報の量が多い 2. 特定の秘密情報は、アプリケーション間で共有する必要がある 3. 秘密情報管理をサービス開発者に権限移譲していきたい
19. 特定の秘密情報は、アプリケーション間で共有する必要がある 前提 　Kubernetes（EKS）クラスタは、マルチテナントアーキテクチャを採用 aaa-web-namespace component-aaa-1 component-aaa-2 bbb-web-namespace component-bbb-1 component-bbb-2 ccc-web-namespace component-ccc-1 component-ccc-2 k8s cluster
20. 特定の秘密情報は、アプリケーション間で共有する必要がある • オンプレミスで稼働するアプリケーションを、 Kubernetes（EKS）に移行 • 歴史的経緯により、アプリケーション間で値を共有しなければならない秘密情報が複数存在 • namespaceをまたいで、秘密情報を共有する必要 があった aaa-web-namespace component-aaa-1 component-aaa-2 bbb-web-namespace component-bbb-1 component-bbb-2 ccc-web-namespace component-ccc-1 component-ccc-2 k8s cluster KubernetesのSecrestリソースは namespaceをまたいで値を共有することができない
21. 特定の秘密情報は、アプリケーション間で共有する必要がある 実現方式 Kubernetesの仕組みに依存しない秘密情報の管理 aaa-web-namespace component-aaa-1 component-aaa-2 bbb-web-namespace component-bbb-1 component-bbb-2 ccc-web-namespace component-ccc-1 component-ccc-2 k8s cluster
22. 秘密情報管理をサービス開発者に権限移譲していきたい 1. 管理対象の秘密情報の量が多い 2. 特定の秘密情報は、アプリケーション間で共有する必要がある 3. 秘密情報管理をサービス開発者に権限移譲していきたい
23. 秘密情報管理をサービス開発者に権限移譲していきたい オンプレミス環境における秘密情報の管理フロー 秘密情報管理サーバ 秘密情報 サービスA チーム サービスB チーム サービスC チーム インフラチーム サービスA サービスB サービスC ① サービスチームから インフラチームに登録依頼 ②　インフラチームが 温かみのある手作業 で登録 ③ デプロイ時に各サービスに反映
24. 秘密情報管理をサービス開発者に権限移譲していきたい 何らかの秘密情報管理ツール サービスA用秘密情報 サービスA チーム サービスB チーム サービスC チーム インフラチーム サービスA サービスB サービスC ① サービスチームが各サービ スの秘密情報を管理 ② 自分たちが管理する秘密情報を 任意のタイミングで反映 サービスB用秘密情報 サービスC用秘密情報 共有秘密情報 目指したい姿
25. 特定の秘密情報は、アプリケーション間で共有する必要がある Vault サービスA用秘密情報 サービスA チーム サービスB チーム サービスC チーム インフラチーム サービスA サービスB サービスC サービスB用秘密情報 サービスC用秘密情報 共有秘密情報 実現方式 Vaultの提供する認証・認可の仕組みを用いて、 適切なアクセスコントロール を実現 それにより秘密情報の管理をサービスチームに委譲することが可能になる
26. アクセスコントロール
27. 適切なアクセスコントロールの為に必要なこと アプリケーション • 特定のグループに属するアプリケーションが • 特定の秘密情報に対する参照の権限を持つこと サービス開発者 • 特定のグループに属するユーザが • 特定の秘密情報に対する追加・更新・削除の権限を持つこと
28. アクセスコントロールを実現するためのVaultの仕組み • Auth Method • Policy
29. Auth Method Auth Methodとはなにか • Vaultに対する認証を行うコンポーネントであり、ユーザに対して Identityと Policyを割り当てることに責務を持つ • 複数のAuth Methodsを有効化することで、組織とVaultのユースケース に応じた認証方法を利用する事が出来る
30. Auth Method 様々なAuth Methodが提供されているので、 ユースケースに応じて選択する $ vault auth enable aws Auth Method 概要 Userpass Auth Method ユーザーネームとパスワードを使った一般的な認証 GitHub Auth Method GitHubのPersonal access tokenを使った認証 AWS Auth Method IAMを使った認証 Kubernetes Auth Method KubernetesのService Account Tokenを使った認証 Auth Methodの有効化
31. Policy Policyとはなにか • 特定の秘密情報に関する認可 ◦ Auth Methodで認証したEntitiyとPolicyが紐づく • 特定のパスへの操作や閲覧を許可あるいは禁止する • HCL/JSONで記載
32. Policy path "secret/*" { capabilities = ["list"] } path "secret/data/service/aaa/*" { capabilities = ["create","read","update","delete"] } aaa_policy.hcl
33. Auto MethodとPolicy Vault Policy （Policy A） Aさん ④ 認証（Auth Method） ① Policyを作成 ② Policyを登録 AさんはPolicy Aで 許可されたパスにアクセスできる Vault role （AさんとPolicy Aが紐づく） ③ role（認証の主体とPolicyを紐付ける設定）を登録
34. 適切なアクセスコントロールの為に必要なこと（再掲） アプリケーション • 特定のグループに属するアプリケーションが • 特定の秘密情報に対する参照の権限を持つこと サービス開発者 • 特定のグループに属するユーザが • 特定の秘密情報に対する追加・更新・削除の権限を持つこと
35. 適切なアクセスコントロールの為に必要なこと（再掲） アプリケーション • 特定のグループに属するアプリケーションが • 特定の秘密情報に対する参照の権限を持つこと サービス開発者 • 特定のグループに属するユーザが • 特定の秘密情報に対する追加・更新・削除の権限を持つこと Kubernetes Auth Method + Policy AWS Auth Method + Policy
36. Kubernetes Auth Method • ServiceAccount Tokenを用いて認証 • roleによってPolicyと紐付ける • 特定のServiceAccountを割り当てたPodは特定の秘密情報にアクセスできる aaa-namespace Kubernetes Vault /secret/service/aaa /secret/service/bbb bbb-namespace aaa-k8s-auth policy bbb-k8s-auth policy aaa-role bbb-role /secret/service/aaa のみ参照可能 /secret/service/bbb のみ参照可能
37. Kubernetes Auth Method bound_service_account_names ["default"] bound_service_account_namespaces ["aaa-namespace"] token_bound_cidrs [] token_explicit_max_ttl 0 token_max_ttl 0 token_no_default_policy false token_num_uses 0 token_period 0 token_policies ["aaa-k8s-auth"] token_ttl 21600 token_type default auth/kubernetes/role/aaa-role
38. Kubernetes Auth Method path "secret/*" { capabilities = ["list"] } path "secret/data/service/aaa/*" { capabilities = ["read"] } aaa-k8s-auth.hcl（Policy）
39. AWS Auth Method • IAM を用いて認証し、Policyと紐付ける • 特定のIAM Entityによって認証されたとき、特定の秘密情報のみ変更できる Vault /secret/service/aaa /secret/service/bbb aaa-aws-auth policy bbb-aws-auth policy aaa-role bbb-role /secret/service/aaa のみ追加更新可能 /secret/service/bbb のみ追加更新可能
40. AWS Auth Method AWS SSOとの連携 • aws cli v2を用いて、各サービスごとのIAM RoleへのSSOログイン • vault cliを用いて、AWS Auth MethodによるVault ログイン ◦ client tokenを取得 • Web UIにclient tokenをコピペ $ vault login -method=aws -field=token -no-store role=aaa-role $ aws sso --profile aaa-developers login
41. AWS Auth Method auth_type iam bound_ec2_instance_id null bound_iam_principal_arn ["arn:aws:iam::XXXXXXXXXXXX:role/aws-reserved/sso.amazonaws.com/us-west-2/AWSReservedSSO_XXX.AAA_DEVELO PERS_0000000000000000"] bound_iam_principal_id ["XXXXXXXXXX"] role_id XXXXXX-XXXX-XXXX-XXXX-XXXXXXXX token_explicit_max_ttl 0 token_max_ttl 3600 token_no_default_policy false token_policies ["aaa-aws-auth"] token_ttl 0 token_type default auth/aws/role/aaa-role
42. AWS Auth Method path "secret/*" { capabilities = ["list"] } path "secret/data/service/aaa/*" { capabilities = ["create", "update", "read", "delete"] } aaa-aws-auth.hcl（Policy）
43. できるようになったこと Vault サービスA用秘密情報 サービスA チーム サービスB チーム サービスC チーム インフラチーム サービスA サービスB サービスC サービスB用秘密情報 サービスC用秘密情報 共有秘密情報 できるようになったこと Kubernetes Auth Method + Policy AWS Auth Method + Policy
44. これから
45. 改善点 • 適切なアクセスコントロールは実現できたが、AWS Auth Methodでのログインフ ローが複雑 ◦ AWS SSOでログイン→Vaultトークンを取得→Web UIにコピペ ◦ 若干面倒 • OIDC Auth Methodの導入 ◦ Azure ADをOIDC Providerとして使ったVaultへのログイン ◦ ログインフローの簡略化を実現
46. まとめ
47. まとめ • Vaultの提供する様々な機能により、秘密情報への柔軟なアクセスコント ロールが実現可能 ◦ 秘密情報管理の権限移譲の仕組みを、様々な基盤上で構築可能 ◦ 組織と事業の拡大に対応する一つの方法論 • 改善を続けてより便利な仕組みにしていきたい
48. We’re hiring!