はじめに
昨年IAMロールが自分自身を引き受ける際のロール信頼ポリシーの評価方法にアップデートがあり、自己参照操作をさせたい場合は自身のIAMロールのARN値を信頼ポリシーに追加することが必須になりました。
https://aws.amazon.com/jp/blogs/security/announcing-an-update-to-iam-role-trust-policy-behavior/
自分が使っている環境では自己参照操作をしていないので関係ないと思ってたのですが、最近掲題の事象が発生して原因が上記の自己参照操作であることがわかったので、備忘もかねて修正方法を書いておきます。
環境
- Windows Server 2019
- aws-cli/2.9.21
EC2にはAdministratorAccessPolicyをつけたIAMロールをアタッチしておきます。
アタッチしたIAMロールの信頼ポリシーは以下の設定がされています。
awscliのconfigには以下のように設定しておきます。
[default]
region = ap-northeast-1
output = json
[profile test-bastion]
role_arn = arn:aws:iam::123456789123:role/test-bation
credential_source = Ec2InstanceMetadata
事象
configを設定してcliを実行すると以下のようにAccessDeniedが発生してアクセスがはじかれてしまいます。
エラー内容を見るとtest-bastionロールに対してAssumeRole操作する権限が足りていないことが原因になっています。
test-bastionロールはEC2にアタッチしたIAMロール名のことなので、暗黙的に自己参照操作が行われていることがわかります。
"arn:aws:sts::123456789123:assumed-role/test-bation/i-xxxxxxxxxxxxxxxxx" は実行が許可されていません。"リソース: arn:aws:iam::123456789123:role/test-bation" に対して "sts:AssumeRole" を実行する権限がありません。
対策1
対策として、configの内容を以下に変更することでAccessDeniedが発生しないようにすることができます。
[profile test-bastion]
region = ap-northeast-1
output = json
configに「Ec2InstanceMetadata」を指定していなくても、EC2にIAMロールがアタッチされていれば自動的にIAMロールの権限を使用してcli操作できます。
対策2
もう一つの対策として、IAMロールの信頼ポリシーに自己参照操作を許可する設定を追加することでもAccessDeniedを解消できます。
信頼ポリシー修正後にcliを実行すると正常に実行できることが確認できます。
おわりに
こちらのドキュメントにも記載がありますが、ロールの暗黙の自己信頼を使用していたユーザーは全体のごく少数らしいので、特別な理由がなければ対策1の方法で設定するのが良いのではないかと思います。
ほとんどのAWSのお客様は、この変更によって全く影響を受けません。すべてのロールのうち、ごく一部（約0.0001%）だけが関係するのです。
2022年6月30日以降に暗黙の自己信頼を使用していないロールはこの事象が起こるようになっているようですので、EC2からIAMロールを使用してcli操作を行う場合はご注意ください。
この記事がどなたかの参考になれば幸いです。