マルチテナントEKSクラスタにおける開発者への権限移譲 CloudNative Days Spring 2021 ONLINE

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

今日話すこと これから まとめ 苦労しているポイント マルチテナントEKSクラスタにおける権限移譲 複数のサービスが本番稼働するプラットフォームの構築

複数のサービスが本番稼働する プラットフォームの構築

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

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

少しだけ深堀り ● AWSアカウントは、サービス単位で払い出す ○ 別途EKSクラスタ専用のアカウントがありTGWで接続 ● Kubernetesクラスタ上では、サービス単位でNamepaceを分離 ○ 今回はこちらについて詳しく紹介 ● Vaultを使った秘匿情報管理の仕組みを構築 ○ CNDT 2020「Vault + EKS + AWS SSOで実現する秘密情報管理」にて詳しく紹介 ● CircleCI / ArgoCDを用いたデプロイパイプラインを構築

マルチテナントEKSクラスタにお ける権限移譲

マルチテナント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

そもそもなぜマルチテナントなのか？ ● マルチテナント/シングルテナントのメリット・デメリットを比較検討 ● 今までインフラチームが全てを管理していた環境から、クラスタの 管理まで一気にサービスチームに委譲するのは、ギャップが大き すぎると判断 ● サービスチームが触ることができる範囲を徐々に広げるために、 マルチテナントを採用

権限移譲の対象 ● インフラに関するコードの管理及びレビュー ● Argo CDのGUIを使ったリソースの参照・操作 ● kubectlを使ったEKSクラスタへのアクセス

権限移譲の対象 ● インフラに関するコードの管理及びレビュー ● Argo CDのGUIを使ったリソースの参照・操作 ● kubectlを使ったEKSクラスタへのアクセス

インフラに関するコードの管理及びレビュー 要件 ● サービスチームにインフラに関するコード（ TerraformやKubernetesのマニフェスト）を管理 して欲しい ○ 大量のサービスが稼働すると、インフラチームが全てのコードに責任を持つことは難し い 実現方式 ● Monorepoで管理 ● 各サービスごとにディレクトリを分割。CODEOWNERSを用いてサービスチームのエ ンジニアが所属するGitHubのTeamをコードオーナーに設定。

マニフェストの管理及びレビュー /services配下に、サービス単位でディレクトリを作成し マニフェストを管理 # /services 以外はインフラチームが管理 * @moneyforward/infra_reviewers # xxx-service /services/xxx-service/** @moneyforward/xxx_reviewers # yyy-service /services/yyy-service/** @moneyforward/yyy_reviewers # zzz-service /services/zzz-service/** @moneyforward/zzz_reviewers CODEOWNERSを設定 Monorepo

権限移譲の対象 ● インフラに関するコードの管理及びレビュー ● Argo CDのGUIを使ったリソースの参照・操作 ● kubectlを使ったEKSクラスタへのアクセス

Argo CDのGUIを使ったリソースの参照・操作 要件 ● サービス開発者にArgo CDのGUIを操作して欲しい ○ デプロイしたリソースの状態確認、 Rolling Updateなど ● ただし他のサービスに影響を及ぼす操作を防ぎたい ○ ログインしたユーザが管理するサービスに閉じた権限のみ付与したい 実現方式 ● AppProject / Application をサービス単位で分割 ● Project RoleによるRBAC ○ 特定のApp Projectに閉じたRBAC これにより、各サービスの開発者が適切な権限でArgo CDのGUIを操作することができる

Project Role roles: - name: developers policies: - p, proj:hoge-service:developers, applications, sync, *-hoge/*, allow - p, proj:hoge-service:developers, applications, action/apps/Deployment/restart, *-hoge/*, allow groups: - moneyforward:hoge_developer ● GitHubのhoge_developerチームに所属しているユーザがログインしたら ● hoge-serviceというAppProjectに属するApplicationで管理するリソースに対して、 Sync及びRestart（Rolling Update）ができる

権限移譲の対象 ● インフラに関するコードの管理及びレビュー ● Argo CDのGUIを使ったリソースの参照・操作 ● kubectlを使ったEKSクラスタへのアクセス

kubectlを使ったEKSクラスタへのアクセス 要件 ● サービス開発者がkubectl経由でEKSクラスタにアクセスできるようにしたい ● ただしマルチテナントなのでクラスタ全体に影響を及ぼす操作を防ぎたい ○ 管理するサービスの Namespaceに閉じた権限のみ付与したい 実現方式 ● aws-auth によるRBAC ○ IAMロールとKubernetesにおけるgroupをマッピング ○ groupに対してサービス開発者に付与する権限を定義したRoleをRoleBinding これにより、各サービスの開発者が適切な権限でEKSクラスタにアクセスすることができる

RBACの流れ Role hoge_developers （group） aws-auth RoleBinding hogeサービスのAWSアカウント EKSクラスタのAWSアカウント hoge IAMロール - rolearn: arn:aws:iam::111111111111:role/AWSReservedSSO_ReadOnly_XXXX username: mf:hoge_developer:{{SessionName}} groups: - mf:hoge_developers apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: hoge-developers roleRef: apiGroup: rbac.authorization.k8s.io kind: Role name: hoge-developers subjects: - kind: Group name: mf:hoge_developers apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: hoge-developers rules: - apiGroups: - batch resources: - cronjobs - jobs verbs: （略）

苦労しているポイント

本番運用が始まって1年ほど経過 ● プラットフォームの本番運用が始まって1年ほど経過 ● 10以上のサービスが本番稼働している ● 「開発者への権限委譲」という文脈で、いくつか課題も見えてきた

ポイント ● 開発者にどこまで権限を付与するべきか（最小権限） ● 初期構築時のレビュワー不足 ● スキルトランスファー（ある程度k8sの知識が必要） ● 乗るサービスが増えると問い合わせの数も増えていく ○ クラスタ管理者のコミュニケーションコスト増

これから

これから ● サービスチームへの運用の委譲を加速 ○ https://moneyforward.com/engineers_blog/2020/12/28/infra-study-abroad/ ● ドキュメントの充実 ● さらなる権限の委譲 ○ 委譲で来ていないコードの管理を委譲 ○ AWS SSOのコード化

まとめ

まとめ ● オンプレからクラウド（EKS）に移行することで間違いなく権限移譲の為の手 札は増えた ○ IaCを徹底することでコード管理をサービスチームへ委譲 ○ Kubernetes/Argo CDのRBACを適切に設計することで、最小権限で運 用を委譲 ● 「作って終わり」ではないということを実感 ○ 文化の醸成・スキトラ ○ 継続的なプラットフォームの改善

We’re hiring! ※記載されている会社名および商品・製品・サービス名（ロゴマーク等を含む）は、各社の商標または各権利者の登録商標です。