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

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

Transcript

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

14. マニフェストの管理及びレビュー
    /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
    

    View Slide

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

    View Slide

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

    View Slide

17. 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）ができる
    

    View Slide

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

    View Slide

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

    View Slide

20. 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:
    （略）
    

    View Slide

21. 苦労しているポイント
    

    View Slide

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

    View Slide

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

    View Slide

24. これから
    

    View Slide

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

    View Slide

26. まとめ
    

    View Slide

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

    View Slide

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

    View Slide