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