背景

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

今使っているポリシーが使えなくなるわけではないですが、これを機に権限周りを見直そうと思います。