背景
企業でAWSを利用しているのであれば企業の共通認証基盤とAWS IAM Identitiy CenterとSSOを構築していると思います。そしてAWSで利用する権限は許可セットとして共通基盤の管理部署によって提供され、ユーザー側からは許可セットのカスタマイズができなくなっていることが多いのでしょうか。
私が関わっているチームでは、共通基盤で使えるIAMロール（許可セットをもとに生成されたもの）の権限が自分たちのチームのユースケースに合わなかったので、スイッチロールすることで自分たちに合った権限を付与することにしました。
同じ許可セットを使う人でもユースケースは異なることがあるので、スイッチロール元の人とIAMロールを絞ることでユースケースに沿った権限管理を実現しました。
このページでは、スイッチロールするときに、誰がどのIAMロールを被っているときにスイッチロールを許可あるいは拒否するかを制限する方法を記述します。
結論
信頼関係にアカウントID、ロール名、セッション名を条件として記述することで実現できます。
以下のような書き方です。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::<アカウントID>:role/<ロール名>"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"sts:RoleSessionName": "<セッション名>"
}
}
}
]
}
arn:aws:iam::<アカウントID>:role/<ロール名>を被った<セッション名>さんだけがスイッチロールできるようになっています。
検証
まずは、スイッチロール先のIAMロールを作成します。
作成画面でいきなり信頼されたエンティティタイプ「カスタム信頼ポリシー」を選んで信頼関係を記述してしまってもよいですが、
今回は権限が絞られていくことを確認するため、「AWSアカウント」を選びます。
同一アカウント内でスイッチロールしたいので↓画像のように選択します。
適当なIAMポリシーをアタッチし、名前を付けてIAMロールを作成すると↓画像の様な信頼関係が出来上がりました。
この記述は、指定したアカウントIDのどのリソースからでもスイッチロールできます。
実際にスイッチロールしてみます。
スイッチロールできましたね。
ではこれからスイッチロールできるIAMのロールを制限していきましょう。
次に、スイッチロールを許可したいIAMロールを確認します。
必要な情報は3つです。
- アカウントID
- IAMロール名
- セッション名
共通基盤経由でAWSにログインし、IAMロール'スイッチロール元A'を被ります。
右上に /<セッション名> 表示されているのでメモします。
スイッチロール先のIAMロールの信頼関係を以下のように編集します。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "<スイッチロール元 AのARN>"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"sts:RoleSessionName": "<自分のセッション名>"
}
}
}
]
}
スイッチロールは成功します。（AWSのUI変更中らしく見た目がコロコロ変わってます）
次に絞れていることを確認するために、別のIAMロール'スイッチロール元 B'からスイッチロールを試みます。
異なるロールからはスイッチロールできないようになっています。
つぎはスイッチロール元B/自分のセッション名からのスイッチロールのみを拒否します。
スイッチロール元 Bからのスイッチロールは失敗し、
スイッチロール元 Aからのスイッチロールは成功します。
まとめ
スイッチロール先の信頼関係でアカウントID、ロール名、セッション名を条件にして誰がどのIAMロールを被っているときにスイッチロールを許可するかを制限することができます。もし私達のようにIAM Identity Centerと外部IdP側で権限を分けられない場合は、今回紹介した方法を試してみてください。