🐫

IAM Identity Center 一通り触ってみた

2024/12/06に公開

以下記事などを参考に一通り触ってみたので、概要をまとめてみた。
AWSBlackbelt_シングルサインオンの設計と運用

Organizationsとの関係性

  • 基本的には、Organization管理のメンバーアカウントへマルチアカウントアクセスを行うことができるように設定して使うのが一般的で、メンバーアカウントにアクセス許可セット(権限)を割り当てて使う。
  • ただ、2023 年 11 月のアップデートにより単独の AWS アカウントでも有効化できるようになったためOrganization無しの単独AWSアカウントを複数の外部orAWSアプリケーションへSSOするためのハブとして使うようなこともできるようになった。(ただし、単独のアカウントで有効化した場合機能に制限がある)

https://dev.classmethod.jp/articles/iam-identity-center-account-instance/

https://dev.classmethod.jp/articles/introduction-2024-aws-iam-identity-center/

アクセス設定

「AWS アカウント」×「ユーザー・グループ」×「アクセス許可セット(権限)」の要素がある。
「どのアカウントのどのユーザーorグループにどんな権限を許可するか?」という視点で考えることになりそう。

  • 以下のポリシーが利用可能
    • AWS マネージドポリシー(AWS 管理ポリシー)
    • カスタマーマネージドポリシー(カスタマー管理ポリシー)
    • インラインポリシー
    • 許可の境界(Permissions boundary)

アクセス許可セットとして設定した内容は、アクセス先のアカウントでは IAM ロールとして作成されます(自動で作成され、ユーザーは変更できません)

インラインポリシーで管理すれば、アクセス先で更新できないようなポリシーが作成されるためインラインポリシーで管理するのが良い。

組織インスタンス、アカウントインスタンスとは

AWS IAM Identity Center を有効化した際はインスタンスが作成されて管理される。
AWS Organizations管理アカウントで有効化した場合は「組織インスタンス」、単独のメンバーアカウントで有効化した場合は「アカウントインスタンス」と呼ばれる。

https://docs.aws.amazon.com/ja_jp/singlesignon/latest/userguide/identity-center-instances.html

  • アカウントインスタンス
    • 複数のAWSアカウントへのシングルサインオン(マルチアカウント管理)はできない。
    • メンバーアカウントからその他アプリケーションへのシングルサインオンはできる。
      • Slack, Salesforceなどの外部サービス
      • AWSマネージドアプリケーション(一覧,Athena,CodeCatalystなど)
  • 組織インスタンス
    • 上記に加えて以下機能が使える
      • マルチアカウントへのシングルサインオン
      • 委任者へのインスタンス管理権限委譲

ID 管理(ユーザー管理)

IAM Identity Center のユーザー管理は、以下2つの方法がある。

  • 外部のIDプロバイダ(Googleやxなど)
  • IAM Identity Center 内のIdentity Center ディレクトリ
    • IAMとは別に管理される独自の認証アカウント管理ディレクトリ

https://dev.classmethod.jp/articles/introduction-2024-aws-iam-identity-center/

Identity Center ディレクトリ

  • 内部でアカウント管理を行う場合、Usersからポータル用アカウントを追加することで認証用アカウントを作成できる。
  • あとは作成した認証用アカウントにAWSアカウントと権限セットを紐づければ良い。(以下画像のアカウントを割り当てるから設定)
  • このようなAWSアカウントと紐づける用の認証アカウントはAWS上で管理するなら Identity Center ディレクトリ を使うことになるが他にもActive Directoryと連携したりGoogle Wookspaceと連携したりできるのでそのうち試したいと思う。(ADの勉強がてら合わせてやりたい)

SwichRoleとの使い分け

複数のアカウントに切り替えが可能という点でSwichRoleと似通っている。

ただ、アカウントごとの細かいロールの設定を管理するのには向いていない印象があるため、スイッチロール元の踏み台アカウントへのアクセス制御用に使ってそれ以降はSwichRoleに任せるのが良い気がしている。(以下画像)

ただ細かいアクセス制御が不要でマネージドポリシーで事足りるなら IAM Identity Center のみで管理するのも良いかもしれない。

https://speakerdeck.com/yhana/aws-iam-identity-center-woshi-wanaimarutiakauntonoyuzaguan-li?slide=25

SwichRole用の権限

SwichRole用のAssumeRoleを許可するポリシーは、上記構成の場合 IAM Identity Center の権限セット作成時のインラインポリシーで作成するのが良さそう。

SwichRole先で IAM Identity Center のユーザーのみ許可する設定は一工夫必要なので注意。
(以下参照)

  • Point: rootアカウントから特定のuserIdの人だけ許可するという設計になる。

https://dev.classmethod.jp/articles/creating-iam-role-restricted-to-specific-iam-adentity-center-users/

Idcの管理権限を委任可能

基本的には、AWS Organizationの管理アカウントから発行したIAM UserでIdCを操作すればいいと思う。

ただ、管理用の別部署アカウントで管理したい場合や、他の複数部署から操作できるようにしたい場合などの時は以下の「委任された管理者」からOrganizationの特定メンバーアカウントに権限を委譲する設計にするといいと思う。

AWS CLIからIAM Identity Center経由でSwichRoleするには

  1. ログイン状態にする設定

手動でconfigを修正して設定する方法と、対話型シェル(ウィザード)から設定する方法がある。

ログインして認証情報を確認する

$ aws sso login --profile my-dev-profile
$ aws sts get-caller-identity --profile my-dev-profile
  1. .aws/configの修正

https://developer.mamezou-tech.com/blogs/2023/07/13/aws-iam-identity-center/

[profile 適当なprofile名]
role_arn = arn:aws:iam::<SwichRole先accout_id>:role/<SwichRole先切り替え用Role名>
source_profile = my-dev-profile

Discussion