背景
AWSを使用するプロジェクトでは多くの場合、システム管理者等がAdministrator権限を持ち、
開発者や運用者はIAMなどの強い権限は持っていないと思います。
例えば開発フェーズやテストで何度も調整を行う際に、毎回管理者が対応するのも大変かと思います。
また、開発環境であれば限定的に権限を付与しても良い場合もあります。
例
「え？IAMの権限なんて使う…？」と思うかもしれませんが
例としては、ECSのAutoScaling設定調整が挙げられます。
ECSのFullAccess権限があったら変更くらいできるだろう、と思いますが
一般的にECSのAutoScalingでは、AutoScaling使用許可する専用のIAMロールを使用しています。
サービス更新画面でいうとこのあたり。
Scalingするためのポリシーとは具体的になんぞや？というと
・トリガーにしているCloudWatchアラームの読取/書込
・サービスの必要タスク数変更
などの権限が挙げられます。
つまり本題に戻ると、ECSの必要タスク数を1から2に変更したい、という場合
「ECSサービスの変更」権限=ECS権限 に加えて
「AutoScaling用Roleを変更する」権限=IAM権限 が必要になります。
開発者がIAM権限を持っていない場合、AccessDeniedとなり変更ができません。
以上のように、AWSユーザのみでなくAWSサービスに対してもIAM権限を与えているケースは多いです。
となると、ユーザが追加でIAM権限が必要になったりします。
だからといってAdministrator権限をむやみに増やせないですよね。
対処法
このような場合は、該当のRoleを変更する権限を、リソースを限定してユーザに与えれば解決します。
今回の例だと、ECSのAutoScalingRoleというリソースのみ、Role変更権限を与えます。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "iam:PassRole",
"Resource": "arn:aws:iam::XXXXXXXXXXXX:role/aws-service-role/ecs.application-autoscaling.amazonaws.com/AWSServiceRoleForApplicationAutoScaling_ECSService"
}
]
}
こちらがサンプルですが、"iam:PassRole"をリソース指定した上で与えます。
因みに今回指定しているRoleは、AWSのマネージドロールのARNです。
まとめ
AWS IAMは、ユーザのみでなくAWSサービスにも権限を与えるものなので、
設計する際は頭の中で整理しないと混乱しますね。。
権限を変更する権限？誰が使うんだっけ？サービス・・・？
ただここを間違うと、必要のない権限まで与えてしまいリスクが大きくなるので、定期的に見直しましょう。
おまけ
そういえば、2021/1/29でECSの管理マネージドポリシーの推奨が変更になります。
従来のポリシーにiam:passroleが入っていますが、リソースもコンディションも限定されていないですね。
https://docs.amazonaws.cn/en_us/AmazonECS/latest/developerguide/managed-policy-transition.html
◆これまでのポリシー（抜粋）
AmazonEC2ContainerServiceFullAccess
"iam:PassRole"
],
"Resource": "*"
◆新しい推奨ポリシー
AmazonECS_FullAccess
https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs_managed_policies.html#AmazonECS_FullAccess
今使っているポリシーが使えなくなるわけではないですが、これを機に権限周りを見直そうと思います。