AWSのサービス諸々ありますが、IAMが一番難しいです…。
それぞれのサービス特有の権限とIAMロールの権限が競合するときや、複数のIAMロールが付与された環境にて優先される権限等、枚挙にいとまがありません。
今回は特にECS on EC2 環境での
- EC2にアタッチしたIAMロール
- ECS タスク起動ロール
が競合した際、どちらが優先されるのか実験したいと思います。
（ECSタスク起動ロールとタスクロールの違いはここでは解説しません💦）
実験
両者が競合する状況として、EC2で起動しているコンテナのCloudWatchへの書き込みを想定しました。
図のような状況です。
この場合、EC2にアタッチしたIAMロール、ECS タスク起動ロールのどちらが優先されるのでしょうか？
ChatGPTさんによると、どちらかに権限があれば書き込みが出来るそうですが...。
手順
ECRにイメージのpush
hello-worldするDockerfileを用意し、ECRにpushします
FROM hello-world
OK
タスクの追加&ECSクラスタの作成
まずはタスクの作成、イメージURlは先ほどpushしたhello-worldイメージのURlをします。
続いてクラスタの作成。
ここまではデフォルトの権限（ecsTaskExecutionRole）を用いています。
この権限にはAmazonECSTaskExecutionRolePolicyのポリシーがついているため、CloudWatchへの書き込みができるはずです！
早速hello-worldしてみましょう！٩( ᐛ )و
大丈夫そうですね！
ではそれぞれのパターンで調査してみます。
結果
| EC2 | ECS | ログ |
|---|---|---|
| あり | あり | ○ |
| なし | あり | ○ |
| あり | なし | ○ |
| なし | なし | x |
ChatGPTさんの言う通りになりました！
なしなしの場合はログ出力がなく、以下のようなエラーメッセージが出てました。
詳細
状況の理由 CannotStartContainerError: Error response from daemon: failed to initialize logging driver: failed to create Cloudwatch log stream: NoCredentialProviders: no valid providers in chain. Deprecated. For verbose messaging see aws.Config.CredentialsChainVerbo
まとめ
IAMにはAllow、Denyの概念もあり、さらにややこしいです。