マルチテナントEKSクラスタにおける開発者への権限移譲
マルチテナントEKSクラスタにおける開発者への権限移譲CloudNative Days Spring 2021 ONLINE
View Slide
自己紹介後藤 健汰(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-namespacecomponent-aaa-1component-aaa-2bbb-web-namespacecomponent-bbb-1component-bbb-2ccc-web-namespacecomponent-ccc-1component-ccc-2k8s cluster
そもそもなぜマルチテナントなのか?● マルチテナント/シングルテナントのメリット・デメリットを比較検討● 今までインフラチームが全てを管理していた環境から、クラスタの管理まで一気にサービスチームに委譲するのは、ギャップが大きすぎると判断● サービスチームが触ることができる範囲を徐々に広げるために、マルチテナントを採用
権限移譲の対象● インフラに関するコードの管理及びレビュー● 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_reviewersCODEOWNERSを設定Monorepo
Argo CDのGUIを使ったリソースの参照・操作要件● サービス開発者にArgo CDのGUIを操作して欲しい○ デプロイしたリソースの状態確認、 Rolling Updateなど● ただし他のサービスに影響を及ぼす操作を防ぎたい○ ログインしたユーザが管理するサービスに閉じた権限のみ付与したい実現方式● AppProject / Application をサービス単位で分割● Project RoleによるRBAC○ 特定のApp Projectに閉じたRBACこれにより、各サービスの開発者が適切な権限でArgo CDのGUIを操作することができる
Project Roleroles:- name: developerspolicies:- p, proj:hoge-service:developers, applications, sync, *-hoge/*, allow- p, proj:hoge-service:developers, applications, action/apps/Deployment/restart, *-hoge/*, allowgroups:- moneyforward:hoge_developer● GitHubのhoge_developerチームに所属しているユーザがログインしたら● hoge-serviceというAppProjectに属するApplicationで管理するリソースに対して、Sync及びRestart(Rolling Update)ができる
kubectlを使ったEKSクラスタへのアクセス要件● サービス開発者がkubectl経由でEKSクラスタにアクセスできるようにしたい● ただしマルチテナントなのでクラスタ全体に影響を及ぼす操作を防ぎたい○ 管理するサービスの Namespaceに閉じた権限のみ付与したい実現方式● aws-auth によるRBAC○ IAMロールとKubernetesにおけるgroupをマッピング○ groupに対してサービス開発者に付与する権限を定義したRoleをRoleBindingこれにより、各サービスの開発者が適切な権限でEKSクラスタにアクセスすることができる
RBACの流れRolehoge_developers(group)aws-auth RoleBindinghogeサービスのAWSアカウント EKSクラスタのAWSアカウントhoge IAMロール- rolearn: arn:aws:iam::111111111111:role/AWSReservedSSO_ReadOnly_XXXXusername: mf:hoge_developer:{{SessionName}}groups:- mf:hoge_developersapiVersion: rbac.authorization.k8s.io/v1kind: RoleBindingmetadata:name: hoge-developersroleRef:apiGroup: rbac.authorization.k8s.iokind: Rolename: hoge-developerssubjects:- kind: Groupname: mf:hoge_developersapiVersion: rbac.authorization.k8s.io/v1kind: Rolemetadata:name: hoge-developersrules:- apiGroups:- batchresources:- cronjobs- jobsverbs:(略)
苦労しているポイント
本番運用が始まって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!※記載されている会社名および商品・製品・サービス名(ロゴマーク等を含む)は、各社の商標または各権利者の登録商標です。