ECSのタスクロールとタスク実行ロールでは権限の使いどころが違う

  • AWS
  • ECS
  • IAM

この記事は、構成と文章の整理にAIを使っています。
あくまで読みやすくするための補助で、内容そのものをAIにすべて任せて書いているわけではありませんが、ところどころ相談しながら整えています。

ECSのタスク定義には「タスク実行ロール」と「タスクロール」という2つのIAMロールが出てくる。名前が似てるせいで最初は混同してたので整理しておく。

結論

  • タスク実行ロール → ECSエージェント（Fargateエージェント） が使うロール。ECRからのイメージpullとCloudWatch Logsへのログ出力が主目的
  • タスクロール → コンテナの中で動くアプリケーション自体 が使うロール。S3やDynamoDBなど実際のAWSサービスに接続するときの権限はこっち

コンテナ内のアプリからは、タスク実行ロールの権限には直接アクセスできないらしい。あくまでエージェントが裏で使うロールという位置づけ。

タスク実行ロール

ECSコンテナエージェントがECS APIを実行するために使うIAMロール。役割は以下の3つ。

  • ECRの認証トークン取得
  • コンテナイメージのダウンロード
  • CloudWatch Logsへのログ出力

デフォルトでアタッチされる AmazonECSTaskExecutionRolePolicy の中身はこんな感じ。

{
  "Effect": "Allow",
  "Action": [
    "ecr:GetAuthorizationToken",
    "ecr:BatchCheckLayerAvailability",
    "ecr:GetDownloadUrlForLayer",
    "ecr:BatchGetImage",
    "logs:CreateLogStream",
    "logs:PutLogEvents"
  ],
  "Resource": "*"
}

マネジメントコンソールで初めてタスク定義を作るときに「新しいロールの作成」を選ぶと ecsTaskExecutionRole が自動生成される。CloudFormationやCDKで構築してる場合はこのロールが存在しないことがあるので、その場合は自分で作る必要がある。

注意点として、Secrets ManagerやSSM Parameter Storeから機密情報を secrets としてコンテナに注入する構成にしている場合、secretsmanager:GetSecretValue や ssm:GetParameters はデフォルトのポリシーには含まれていないので、別途タスク実行ロールに追加する必要がある。

タスクロール

ECSタスクで定義されたコンテナ自体に紐づくIAMロール。コンテナ内のアプリケーションコードがAWS SDKやCLIを使って実際のAWSサービス（S3, DynamoDB, SQSなど）に接続するときに、この権限が使われる。

EC2起動タイプの場合、タスクロールを使うことでEC2インスタンスプロファイル側の権限を変更せずに、コンテナ単位で個別の権限を割り当てられるのがメリット。Fargateの場合はそもそもインスタンスプロファイルという概念がないので、タスクロールが唯一の権限付与手段になる。

図にするとこう

flowchart LR
    subgraph ECSタスク
        Agent[ECSエージェント / Fargateエージェント]
        App[コンテナ内アプリケーション]
    end

    ExecRole[タスク実行ロール]
    TaskRole[タスクロール]
    ECR[(ECR)]
    Logs[(CloudWatch Logs)]
    AWS_API[(S3 / DynamoDB など)]

    Agent -->|assume| ExecRole
    ExecRole --> ECR
    ExecRole --> Logs

    App -->|assume| TaskRole
    TaskRole --> AWS_API

まとめ方

迷ったらこう覚えておけばよさそう。

  • 「タスクを 動かす ためのロール」＝タスク実行ロール
  • 「タスクの中の アプリが動く ためのロール」＝タスクロール

権限は最小限にしておくのが基本なので、タスクロールに無闇にAdministratorAccess的な広い権限を付けないように気をつけたい。