Tweet
Tweet

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

自己紹介 後藤 健汰（gotoken） @kennygt51 ● SIerでの運用系SEを経て、 2019年1月 マネーフォワード入社 ● インフラエンジニア ● アプリケーションのコンテナ化、サービ スのAWS移行

Slide 3

Slide 3 text

今日話すこと なぜVaultを選んだのか？ アクセスコントロール Kubernetes（EKS）における秘密情報管理 AWS移行プロジェクト マネーフォワードについて これから まとめ

Slide 4

Slide 4 text

マネーフォワードについて

Slide 5

Slide 5 text

すべての人生を、 便利で豊かにする。 ビジネスの成長を加速させる。 くらしの経済メディア お金の見える化サービス 金融商品の比較・申し込みサイト 自動貯金アプリ お金を前へ。人生をもっと前へ。 パートナーと共に、 新たな金融サービスを創出する。 お金をいい方向へと動かす。 for ○○ 金融機関お客様向け自動家計簿・ 資産管理サービス 通帳アプリ 金融機関お客様向け通帳アプリ MF Unit 金融機関のアプリへの一部機能提供 企業間後払い決済サービス 売掛金早期資金化サービス BFM 法人向け資金管理サービス 成長企業向けフィナンシャル・ アドバイザリーサービス バックオフィス向け業務効率化ソリューション マネーフォワード MEユーザーのための FP相談窓口 マネーフォワード MEのデータを分析し最 適な行動をアドバイス DX人材特化のキャリア支援サービス

Slide 6

Slide 6 text

AWS移行プロジェクト

Slide 7

Slide 7 text

AWS移行プロジェクト ● 2012 年の創業当初からオンプレミス＠北海道 ○ 物理サーバーを購入し、インフラ担当者がセットアップし運用 ● 2018年下旬頃より、AWS移行プロジェクトが発足 ○ オンプレミスで稼働するサービスの漸進的マイグレーション ● 2020年9月現在、複数サービスがAWS上で本番稼働中

Slide 8

Slide 8 text

マルチテナントEKS及びマルチアカウントアーキテクチャ ● マルチテナントEKS及びマルチアカウントアーキテクチャを採用 ● オンプレミス環境で稼働するサービスの移行及び新規サービスの受入を行ってい る 詳細については 弊社のエンジニアが登壇する 　　AWS Summit Online をチェック！

Slide 9

Slide 9 text

Kubernetes（EKS）における 秘密情報管理

Slide 10

Slide 10 text

Kubernetes（EKS）における秘密情報管理 Kubernetes（EKS）クラスタで扱う秘密情報どう管理するか？ ● どこに 秘密情報を保存するのか？（可用性を担保） ● どのように アプリケーションから利用するのか？ ● だれが 秘密情報を管理（追加/変更/削除）するのか

Slide 11

Slide 11 text

Kubernetes（EKS）で利用する秘密情報管理の仕組み Kubernetes（EKS）で利用する秘密情報をする仕組みの一例 ・KubernetesのSecretsリソース ・Sealed Secrets ・AWS Secrets Manager ・HashiCorp Vault

Slide 12

Slide 12 text

HashiCorp Vaultとは何か HashiCorp Vaultとは HashiCorp社が開発したOSS 秘密情報を管理・保護する為のソフトウェア 特徴 ● 秘密情報の保存先は拡張性が高く、様々なコンポーネントから選択可能（ Storage Backend） ● 様々な秘密情報を管理できる（ Secret Engine） ● IdentityにPolicyを割り当てることで柔軟な認可の制御ができる（ Auth Method） ● 認証により発行された Tokenは時間ベースでRevokeされる（Client Token）

Slide 13

Slide 13 text

なぜVaultを選んだのか？

Slide 14

Slide 14 text

実現したかったこと 実現したい要求の中で、特に以下の3点を重視 1. 管理対象の秘密情報の量が多い 2. 特定の秘密情報は、アプリケーション間で共有する必要がある 3. 秘密情報管理をサービス開発者に権限移譲していきたい 上記の3つの要求を実現可能であることからVaultを採用

Slide 15

Slide 15 text

管理対象の秘密情報の量が多い 1. 管理対象の秘密情報の量が多い 2. 特定の秘密情報は、アプリケーション間で共有する必要がある 3. 秘密情報管理をサービス開発者に権限移譲していきたい

Slide 16

Slide 16 text

管理対象の秘密情報の量が多い ● マネーフォワードは多くのサービスを提供している ● そのため、管理すべき秘密情報はかなりの量になる ● 大量の情報を、効率的に管理したかった

Slide 17

Slide 17 text

管理対象の秘密情報の量が多い 実現方式 ● パスベースで、Key-Value形式の秘密情報を管理 ○ KV Secrets Engineを有効化 ● 使いやすいWeb UI

Slide 18

Slide 18 text

特定の秘密情報は、アプリケーション間で共有する必要がある 1. 管理対象の秘密情報の量が多い 2. 特定の秘密情報は、アプリケーション間で共有する必要がある 3. 秘密情報管理をサービス開発者に権限移譲していきたい

Slide 19

Slide 19 text

特定の秘密情報は、アプリケーション間で共有する必要がある 前提 　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

Slide 20

Slide 20 text

特定の秘密情報は、アプリケーション間で共有する必要がある ● オンプレミスで稼働するアプリケーションを、 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をまたいで値を共有することができない

Slide 21

Slide 21 text

特定の秘密情報は、アプリケーション間で共有する必要がある 実現方式 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

Slide 22

Slide 22 text

秘密情報管理をサービス開発者に権限移譲していきたい 1. 管理対象の秘密情報の量が多い 2. 特定の秘密情報は、アプリケーション間で共有する必要がある 3. 秘密情報管理をサービス開発者に権限移譲していきたい

Slide 23

Slide 23 text

秘密情報管理をサービス開発者に権限移譲していきたい オンプレミス環境における秘密情報の管理フロー 秘密情報管理サーバ 秘密情報 サービスA チーム サービスB チーム サービスC チーム インフラチーム サービスA サービスB サービスC ① サービスチームから インフラチームに登録依頼 ②　インフラチームが 温かみのある手作業 で登録 ③ デプロイ時に各サービスに反映

Slide 24

Slide 24 text

秘密情報管理をサービス開発者に権限移譲していきたい 何らかの秘密情報管理ツール サービスA用秘密情報 サービスA チーム サービスB チーム サービスC チーム インフラチーム サービスA サービスB サービスC ① サービスチームが各サービ スの秘密情報を管理 ② 自分たちが管理する秘密情報を 任意のタイミングで反映 サービスB用秘密情報 サービスC用秘密情報 共有秘密情報 目指したい姿

Slide 25

Slide 25 text

特定の秘密情報は、アプリケーション間で共有する必要がある Vault サービスA用秘密情報 サービスA チーム サービスB チーム サービスC チーム インフラチーム サービスA サービスB サービスC サービスB用秘密情報 サービスC用秘密情報 共有秘密情報 実現方式 Vaultの提供する認証・認可の仕組みを用いて、 適切なアクセスコントロール を実現 それにより秘密情報の管理をサービスチームに委譲することが可能になる

Slide 26

Slide 26 text

アクセスコントロール

Slide 27

Slide 27 text

適切なアクセスコントロールの為に必要なこと アプリケーション ● 特定のグループに属するアプリケーションが ● 特定の秘密情報に対する参照の権限を持つこと サービス開発者 ● 特定のグループに属するユーザが ● 特定の秘密情報に対する追加・更新・削除の権限を持つこと

Slide 28

Slide 28 text

アクセスコントロールを実現するためのVaultの仕組み ● Auth Method ● Policy

Slide 29

Slide 29 text

Auth Method Auth Methodとはなにか ● Vaultに対する認証を行うコンポーネントであり、ユーザに対して Identityと Policyを割り当てることに責務を持つ ● 複数のAuth Methodsを有効化することで、組織とVaultのユースケース に応じた認証方法を利用する事が出来る

Slide 30

Slide 30 text

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の有効化

Slide 31

Slide 31 text

Policy Policyとはなにか ● 特定の秘密情報に関する認可 ○ Auth Methodで認証したEntitiyとPolicyが紐づく ● 特定のパスへの操作や閲覧を許可あるいは禁止する ● HCL/JSONで記載

Slide 32

Slide 32 text

Policy path "secret/*" { capabilities = ["list"] } path "secret/data/service/aaa/*" { capabilities = ["create","read","update","delete"] } aaa_policy.hcl

Slide 33

Slide 33 text

Auto MethodとPolicy Vault Policy （Policy A） Aさん ④ 認証（Auth Method） ① Policyを作成 ② Policyを登録 AさんはPolicy Aで 許可されたパスにアクセスできる Vault role （AさんとPolicy Aが紐づく） ③ role（認証の主体とPolicyを紐付ける設定）を登録

Slide 34

Slide 34 text

適切なアクセスコントロールの為に必要なこと（再掲） アプリケーション ● 特定のグループに属するアプリケーションが ● 特定の秘密情報に対する参照の権限を持つこと サービス開発者 ● 特定のグループに属するユーザが ● 特定の秘密情報に対する追加・更新・削除の権限を持つこと

Slide 35

Slide 35 text

適切なアクセスコントロールの為に必要なこと（再掲） アプリケーション ● 特定のグループに属するアプリケーションが ● 特定の秘密情報に対する参照の権限を持つこと サービス開発者 ● 特定のグループに属するユーザが ● 特定の秘密情報に対する追加・更新・削除の権限を持つこと Kubernetes Auth Method + Policy AWS Auth Method + Policy

Slide 36

Slide 36 text

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 のみ参照可能

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

Kubernetes Auth Method path "secret/*" { capabilities = ["list"] } path "secret/data/service/aaa/*" { capabilities = ["read"] } aaa-k8s-auth.hcl（Policy）

Slide 39

Slide 39 text

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 のみ追加更新可能

Slide 40

Slide 40 text

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

Slide 41

Slide 41 text

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

Slide 42

Slide 42 text

AWS Auth Method path "secret/*" { capabilities = ["list"] } path "secret/data/service/aaa/*" { capabilities = ["create", "update", "read", "delete"] } aaa-aws-auth.hcl（Policy）

Slide 43

Slide 43 text

できるようになったこと Vault サービスA用秘密情報 サービスA チーム サービスB チーム サービスC チーム インフラチーム サービスA サービスB サービスC サービスB用秘密情報 サービスC用秘密情報 共有秘密情報 できるようになったこと Kubernetes Auth Method + Policy AWS Auth Method + Policy

Slide 44

Slide 44 text

これから

Slide 45

Slide 45 text

改善点 ● 適切なアクセスコントロールは実現できたが、AWS Auth Methodでのログインフ ローが複雑 ○ AWS SSOでログイン→Vaultトークンを取得→Web UIにコピペ ○ 若干面倒 ● OIDC Auth Methodの導入 ○ Azure ADをOIDC Providerとして使ったVaultへのログイン ○ ログインフローの簡略化を実現

Slide 46

Slide 46 text

まとめ

Slide 47

Slide 47 text

まとめ ● Vaultの提供する様々な機能により、秘密情報への柔軟なアクセスコント ロールが実現可能 ○ 秘密情報管理の権限移譲の仕組みを、様々な基盤上で構築可能 ○ 組織と事業の拡大に対応する一つの方法論 ● 改善を続けてより便利な仕組みにしていきたい

Slide 48

Slide 48 text

We’re hiring!