AWS IAM Identity Center では、AWS Organizations 管理外の AWS アカウントもアプリケーションとして追加してアクセスできます。便利な機能なのですが、アクセス先アカウントに ID プロバイダーも作成する必要があるなど設定は少し手間です。そこで、一度 AWS Organizations 管理下のアカウントにアクセスしてから、AWS Organizations 管理外のアカウントにスイッチロールする構成を試してみました。
本ブログで試してみた構成図です。踏み台アカウントという名前は本ブログ上での名称です。
なお、AWS IAM Identity Center から AWS Organizations 管理外の AWS アカウントへのアクセスを設定する方法を知りたい場合は下記ブログで紹介されています。AWS IAM Identity Center から一元的にアクセスする方が分かりやすい構成となり、運用しやすい面もあります。
AWS IAM Identity Center 経由でスイッチロール
AWS IAM Identity Center から踏み台アカウント経由で AWS Organizations 管理外のアカウントにスイッチロールする設定と実際にアクセスするところまでをやってみました。
AWS IAM Identity Center の設定
AWS IAM Identity Center の設定では、スイッチロールができる権限のアクセス許可セットを作成します。今回はAssumeRoleOnlyAccessという名前にして、下記のインラインポリシーをアタッチしてみました。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"sts:AssumeRole"
],
"Resource": [
"*"
]
}
]
}
作成したアクセス許可セットを踏み台アカウントに関連付けます。関連付けた後のアクセスポータルの画面です（検証環境上では踏み台アカウントは Sandbox-03 という名前のアカウントです）。
踏み台アカウント上では、下図の IAM ロールが AWS IAM Identity Center によって作成されています。なお、AssumeRoleOnlyAccess権限で踏み台アカウントにアクセスしている場合は、IAM ロールを閲覧できません（権限がありません）。そのため、ReadOnlyAccess 権限などで確認する必要があります。
作成された IAM ロールをスイッチロール先アカウントから信頼することでスイッチロールを実現します。信頼ポリシーでは、IAM ロールの ARN を指定します。
スイッチロール先アカウントの設定
最終的にアクセスしたいスイッチロール先アカウントでは、 IAM ロールを作成します。
IAM ロールの信頼ポリシーでは、踏み台アカウントにおける AWS IAM Identity Center が作成した IAM ロールを信頼します。
今回の例では、IAM ロールにアタッチする IAM ポリシーはAdministratorAccessとして、下記の信頼ポリシーを設定しました。Principalには踏み台アカウントの IAM ロールの ARN を指定しています。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111122223333:role/aws-reserved/sso.amazonaws.com/ap-northeast-1/AWSReservedSSO_AssumeRoleOnlyAccess_150439ae95bbfe34"
},
"Action": "sts:AssumeRole"
}
]
}
ロール名をAdministratorAccessRoleとして作成した例です。
アクセステスト
AWS IAM Identity Center から踏み台サーバでスイッチロール先アカウントにアクセスしてみます。
まずは、AWS IAM Identity Center からAssumeRoleOnlyAccess権限で踏み台アカウントにアクセスします。
踏み台アカウントのマネジメントコンソール上で「ロールの切り替え」を選択します。
「ロールの切り替え」をクリック後に、スイッチロール先アカウントにスイッチロールします。「アカウント」に入力するのはスイッチロール先アカウントのアカウント ID です。「ロール」には踏み台アカウントで作成した IAM ロール名を入力します。「表示名」は任意の値で問題ありませんが、今回はロール名と同様にしました。
想定通り、アクセスできました。
少し話が逸れますが、ロールの切り替えは Chrome 拡張機能 AWS Extend Switch Roles を使うと簡単に管理できます。
スイッチロール先アカウント内で、試しに EC2 インスタンスを起動した後に CloudTrail のイベントログを確認したところ、今回利用した AWS IAM Identity Center のユーザー名であるtest-userの情報がarnに記録されていました。
{
"eventVersion": "1.09",
"userIdentity": {
"type": "AssumedRole",
"principalId": "AROA5VOZMRYTA4EXAMPLE:test-user",
"arn": "arn:aws:sts::444455556666:assumed-role/AdministratorAccessRole/test-user",
"accountId": "444455556666",
"accessKeyId": "ASIA5VOZMRYTFRNFXGMK",
"sessionContext": {
"sessionIssuer": {
"type": "Role",
"principalId": "AROA5VOZMRYTA4EXAMPLE",
"arn": "arn:aws:iam::444455556666:role/AdministratorAccessRole",
"accountId": "444455556666",
"userName": "AdministratorAccessRole"
},
"attributes": {
"creationDate": "2024-01-30T14:35:26Z",
"mfaAuthenticated": "false"
}
}
},
"eventTime": "2024-01-30T14:40:58Z",
"eventSource": "ec2.amazonaws.com",
"eventName": "RunInstances",
"awsRegion": "ap-northeast-1",
（以下、省略）IAM ロールの信頼ポリシーの別案
スイッチロール先アカウントの IAM ロールの信頼ポリシーとして、特定のアクセス許可セット名で絞らず、すべてのアクセス許可セットをまとめて信頼する方法でもスイッチロールできました。ただし、この方法とする場合は、踏み台アカウントへアクセスできるメンバーを絞るなど、他の方法でアクセスを制限しておかないと広く許可される点に注意が必要です。
アクセス許可セットをまとめて信頼する IAM ロールの信頼ポリシーの例です。Principalではロール名の一部をワイルドカードで指定できないため、Condtion でワイルドカード指定をしています。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111122223333:root"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringLike": {
"aws:PrincipalArn": "arn:aws:iam::111122223333:role/aws-reserved/sso.amazonaws.com/ap-northeast-1/AWSReservedSSO_*"
}
}
}
]
}さいごに
AWS IAM Identity Center から AWS Organizations 管理下のアカウントにアクセスした後に、AWS Organizations 管理外のアカウントにスイッチロールする構成を試してみました。
AWS IAM Identity Center にアプリケーションとして AWS Organizations 管理外のアカウントを追加する場合と比べて手順が少なく、CloudFormation で簡単にスイッチロール先アカウントの設定ができる点がメリットと思いました。一方で、多段でアクセスすることになるため、アクセス経路が複雑化することになります。
関連するブログとして、特定の IAM Identity Center ユーザーのみ AssumeRole できる IAM ロールを作成する方法のブログもあります。
5
