はじめに
AWSのIAMポリシーをいじっていていたときに、「ルートユーザのARN」が示すものがよくわからなくなってしまったので、整理して残しておきたいと思います。
結論
ルートユーザのARNは、使用するポリシーやポリシー内のどこで使用されるかによって扱いが異なります。
通常は・・・
アカウント内のIAMエンティティを示します。IAMユーザ、IAMロールですね。
例外として・・・
AWS Organizationsにて、SCPで利用される場合、アカウントのルートユーザ自体を示します。
ルートユーザのARN
ルートユーザのARNは以下のように表されます。
arn:aws:iam::123456789012:root
ルートユーザのARNの使用例
Principalの指定に使用する
例えば、IAMロールにスイッチロールする場合、IAMロールの信頼ポリシーでは、以下のようにスイッチ元のAWSアカウントを"Principal"に指定するかと思います。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": { "AWS": "arn:aws:iam::123456789012:root" },
"Action": "sts:AssumeRole"
}
]
}
この場合は、アカウントID 123456789012のアカウント内のIAMユーザは、上記信頼ポリシーが設定されたIAMロールにスイッチロールすることができます。
PrincipalにルートユーザのARNが指定されており、ここでARNが示すものは「アカウントID 123456789012のアカウント内のIAMユーザ、ロール」です。
余談ですが、ルートユーザはスイッチロールができません。
コンソールでのロールの切り替えに関する主要事項
AWS アカウントのルートユーザー としてサインインすると、ロールを切り替えることはできません。IAM ユーザーとしてサインインしているときに、ロールを切り替えることができます。
あと、
ロールからロールへのスイッチは「ロールの連鎖（Role chaining）」と言うそうです。かっこいい。
IAMロールの信頼ポリシーで使用する以外にも、Principalの指定で使用されるケースとしてはS3バケットへのアクセス許可などがあります。
追加条件付きでの複数のアカウントへのアクセス許可の付与
AWS Organizations SCPに使用する
Organizationsを利用している場合、SCPを利用することでルートユーザによる操作も制限することができます。
以下の例の場合、SCPとしてポリシーが適用されたアカウントのルートユーザはEC2に関する操作ができなくなります。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "RestrictEC2ForRoot",
"Effect": "Deny",
"Action": [
"ec2:*"
],
"Resource": [
"*"
],
"Condition": {
"StringLike": {
"aws:PrincipalArn": [
"arn:aws:iam::*:root"
]
}
}
}
]
}
ConditionにてルートユーザのARNが指定されていますが、ここでARNが示すものは「アカウントのルートユーザのみ」です。
このように、ルートユーザのARNは使用されるされるポリシーによって扱いが異なっています。
なぜ異なるのか（想像）
あくまで想像ですが・・・
AWS Organizationsが登場するまでは、ルートユーザは制限なく何でもできるユーザであり、逆に制限をかけるという発想がなく、IAMエンティティをまとめて表現するためにルートのARNが利用されていたのではないでしょうか。
（Organizationsが登場したとき、僕はまだ社会人1年目でAWSの存在すら知らなかったです...）
ところが、Organizationsの登場によりルートユーザにも制限をかけたいシーンが出てきたために、SCPでは例外的にルートユーザを示すようになっているのではないかと思います。
まとめ
ルートユーザのARNは使用されるにポリシーによって扱いが異なる、と言うお話でした！
初めてこのような記事を書くので、読みづらい部分が多いかと思いますが、どなたかのお役に立てれば幸いです。