MIXI で運用管理しているとある AWS Organizations にて AWS IAM Identity Center (以下 IdC)を導入しました。また、各 AWS アカウント管理者の裁量によって IdC の権限設定を可能にするためにセルフサービス化を行いました。
本記事では IdC の概要、IdC の権限設定をセルフサービス化した理由と実現方法について記載します。
AWS IAM Identity Center 概要
IdC は AWS アカウントへのシングルサインオン(SSO)を提供するサービスです。IAM User による AWS アカウントログインを代替することが可能で、IdC を導入することで以下のようなメリットが挙げられます。
- 複数 AWS アカウントへのログインがスムーズ
- IdP と連携させることでユーザ/グループ管理を IdP 側に任せられる
- AWS CLI v2 を利用した一時的な認証情報の取得が可能
本記事では IdC の運用にフォーカスするため、仕組みの詳細については割愛しますが、より詳しく知りたい方には以下をおすすめします。
前提
とても便利な IdC ですが、IdC の導入を進めていく中で権限設定運用に関して難点があることが分かりました。この難点を説明する前に、前提として今回 IdC を導入した AWS Organizations の管理体系と IdC の権限設定に関する制約について説明します。
今回 IdC を導入した AWS Organizations の管理体系
今回対象となる AWS Organizations には組織横断でエンジニアリングを支援する開発本部とプロダクトの開発/運用を行う事業部がステークホルダーとして存在します。
開発本部の主な役割としては AWS アカウントの発行、請求管理、AWS Organizations 全体のガバナンス管理などがあるため、これら作業に関連する AWS アカウントの管理に責任を持ちます。
一方、事業部はプロダクト提供のために必要な AWS アカウントの運用に責任を持ちます。もちろん各アカウントの IAM に関する管理も事業部が責任を持ちます。
AWS Organizations の管理体系
IdC の権限設定に関する制約
IdC では以下3要素の組み合わせで権限設定を行います。
- ユーザ/グループ
- アクセス権限セット
- AWS アカウント
これら3要素を指定した assignment(割り当て)を行うことで権限設定が可能ですが、以下の AWS アカウントからしか権限設定が行えない制約があります。
- AWS Organizations 管理アカウント(マスターアカウント)
- IdC 管理アカウント(委任アカウント)
AWS のベストプラクティスとして IdC の管理機能を委任したアカウントを利用するべきという記載もあるため、今回は委任アカウントとして IdC 管理アカウントを新しく設けてそのアカウント内で権限設定を行う立て付けにしました。
特定の AWS アカウント上でのみ IdC の権限設定が可能
IdC の権限設定に関する運用をどうするか
事業部を跨った複数の AWS アカウントに関する設定となるため、委任アカウント自体は開発本部による管理が妥当です。しかし、前述の AWS Organizations の管理体系からも分かる通り、各 AWS アカウントへ誰がどんな権限を付与するかは事業部側で決めるものです。そこで考えられる運用案として以下2つが出ました。
事業部からの依頼ベースで開発本部が権限設定を行う
事業部からの権限設定の変更依頼を受けて開発本部が対応します。こちらのメリットとしては権限設定の変更を中央集権的に行うため、ガバナンスを効かせられることです。一方でデメリットとしては開発本部としても他の多くのタスクを抱えている中で IdC の管理業務に割くことができるリソースが限られているという背景の中で、企業の成長に伴ってアカウント数が増えた場合に権限設定管理の負荷が増大し開発本部がボトルネックとなる可能性があることです。
事業部が権限設定を行う
事業部に IdC の権限設定を行う権限を与えて、セルフサービスで IdC の権限設定を行えるようにします。こちらのメリットとしては事業部で権限設定を完結できるため、開発本部がボトルネックになることがありません。一方で IdC の全ての権限設定を単一の IdC 管理アカウント上で行うため、権限設定を行う権限を絞っておかないと間違えて他の事業部が管理している AWS アカウントの IdC 設定を変更してしまうといったリスクもあります。
セルフサービスかつ、統制を効かせた IdC の権限設定
上記2つの運用案を基にして、以下の要件を満たす運用を立てつけられると幸せになりそうです。
- 事業部側で IdC の権限設定を完結できるようにセルフサービス化する
- 他事業部の権限設定を無断で行えないように統制をかける
これを実現するために最終的には以下の構成で IdC の権限設定フローを立てつけました。
順番に説明します。
IdC の権限定義を Terraform 管理するための GitHub リポジトリを用意
MIXI ではインフラの構成管理を IaC 化する文化が根付いており、IdC の権限定義も IaC 化しています。IaC ツールには社内でも利用実績が多い Terraform を採用し、開発本部にて用意した GitHub リポジトリで管理しています。
ディレクトリ構成は事業部やプロダクト単位でディレクトリを切って、それぞれを Terraform の root module としています。このディレクトリ内に IdC の権限設定を定義していきます。定義時に利用するリソースの一例は以下になります。各リソースの詳細は公式ドキュメントを参照ください。
- Resource
- aws_ssoadmin_permission_set
- aws_ssoadmin_managed_policy_attachment
- aws_ssoadmin_permission_set_inline_policy
- aws_ssoadmin_account_assignment
- Data Resource
- aws_identitystore_user
- aws_identitystore_group
また、CI/CD ワークフロー設定等の IdC 権限設定以外は commonディレクトリ内で定義しています。こちらで管理するリソースについては後述します。
GitHub code owners による統制
GitHub には code owners という機能があり、特定ディレクトリに対して GitHub アカウント や Team を code owners として設定できます。code owners と branch protection rule を組み合わせることで PR マージの条件に code owners による approve を必須にするといったことが可能です。
今回は各ディレクトリに対となる GitHub Team を作成し、Team メンバーはディレクトリ内で IdC 権限設定を行う AWS アカウントの管理者としています。この GitHub Team を各ディレクトリの code owners として設定します。また、branch protection rule で PR マージの条件に code owners による approve を必須とするように設定しました。また、commonや moduleといった統制に関する設定を管理するディレクトリには開発本部のメンバーを code owners としています。
ディレクトリ構成と code owners の設定例は以下になります。
.
├── .github
│ └── CODEOWNERS
└── terraform
├── common
├── module
├── A-division
│ └── main.tf
└── B-division
└── main.tf
/.github/ @idc-management/octo
/terraform/common/ @idc-management/octo
/terraform/module/ @idc-management/octo
/terraform/A-division/ @idc-management/a-division
/terraform/B-division/ @idc-management/b-division
各ディレクトリに紐づく HCP Terraform Workspace を用意
Terraform の CI/CD ワークフローには HCP Terraform を採用しました。各ディレクトリに対となる HCP Terraform Workspace を用意しています。Workspace の設定自体はTerraform module として定義し、common ディレクトリ内から呼び出して利用しています。
各 HCP Terraform Workspace に与えるプロビジョニング権限を絞る
HCP Terraform は AWS との間で OpenID Connect（OIDC）連携をサポートしています。これにより、HCP Terraform と信頼関係を結んだ IAM Role から動的に発行されたクレデンシャルを使用して、リソースのプロビジョニングを行うことができます。今回は各 HCP Terraform Workspace と信頼関係を結んだ IAM Role をそれぞれ用意しています。
ここで重要となるのが、各 IAM Role に付与する Policy です。統制のためにも各ディレクトリで assignment 定義できる AWS アカウントは絞る必要があります(例：A-division ディレクトリ内では A-division が管理している AWS アカウントの assignment のみできるようにする)。この Policy 定義は AWS Blog で公開されている Delegating permission set management and account assignment in AWS IAM Identity Centerを参考にしました。この Blog の中で3パターンの統制 model が紹介されていますが、私達はこの中の最も委任する範囲が広い Tag-based model を採用しました。model の詳細は Blog の記載に委ねますが、ざっくり説明すると以下の統制が可能です。
- 特定のタグが付与された権限セットの作成/更新/削除を許可
- 特定のタグが付与された権限セット、及び特定の AWS アカウントに対する assignment を許可
これら IAM Role や Policy についても Terraform module として定義し、common ディレクトリ内から呼び出して利用しています。
IdC による権限管理開始フロー
上記の説明を踏まえて、各事業部の AWS アカウント管理者が IdC による権限管理を導入したいとなった場合のフローは以下としています。
- 事業部：slack workflow から利用申請を出してもらう。申請時に IdC で管理させたい AWS アカウント ID、code owners に設定する GitHub アカウント 等を入力してもらう。
- 開発本部：申請情報を基に code owners 設定、HCP Terraform Workspace 作成、HCP Terraform と信頼関係を結んだ IAM Role の作成等を行う。
- 事業部：権限設定を Terraform で定義する。変更依頼は PR を介して行い、code owners の approve を貰えればマージできる。つまりセルフサービスで設定が可能。
今後の課題
上記で説明した内容で比較的問題なく IdC の運用を回せていますが、いくつか課題も見えてきています。
IAM User での運用に慣れている事業部では IdC への移行に積極的ではない
AWS としてもセキュリティや開発者体験的に IAM User よりも IdC 推奨していることから MIXI でも IdC をデファクトスタンダードとして利用していきたいと考えています。しかし、IAM User での運用に慣れている事業部では IdC への移行に積極的ではない場合もあります。そのため、全社横断で行っている AWS セキュリティ監視項目で IAM User の存在チェックを追加し、IAM User を利用している事業部があれば、AWS アカウント管理者に IdC への移行メリットを説明し、移行を促すことを検討しています。
Terraform に慣れているメンバーがいない
状況によっては事業部側に Terraform に慣れているメンバーが誰もおらず、IdC の導入に踏み切れない場合がありえます。こちらの対処としては定義で利用する Terraform リソースがそこまで複雑では無いので開発本部からのオンボーディングを手厚くしたり、一般的に良く利用する権限が付与された権限セットを開発本部側で用意して別ファイルに切り出したユーザ一覧のみを修正すれば権限設定ができるような立て付けを予定しています。
手動で行う初期設定が煩雑
slack workflow で利用申請を受け付けた後に開発本部側で code owners 設定等の初期設定が必要になります。この初期設定の手順を内部ドキュメントとしてまとめてはいるのですが、手動で行う設定が多く、煩雑となっています。こちらの対処としては必要な設定を全て IaC 化して slack workflow の input から設定差分の PR を自動生成して開発本部メンバーは自動生成された PR のレビューとマージのみを行うようにする予定です。
まとめ
IdC の権限設定をセルフサービス化した理由と実現方法について説明しました。IdC の運用まで含んだ公開事例が少なく、運用設計にとても苦労しましたが AWS の SA さんに相談に乗ってもらったりしながら運用を開始することができました。IdC の運用に困っている方の参考になれば幸いです。
Discussion