ECS Task Role vs Task Execution Role: A 3-Minute Guide to Least Privilege
Two IAM roles attach to every ECS task, and mixing them up is one of the most common causes of over-permissioned containers. Here is what each one does and how to keep both tight.
Every ECS task can have two IAM roles, and they are used by different things.
Task execution role is used by ECS itself to start your task. It typically needs to:
- Pull the container image from Amazon ECR
- Write logs to CloudWatch Logs
- Fetch secrets from Secrets Manager or Parameter Store
- Task role is used by your application code inside the container. It should hold only what the app calls at runtime, such as reading one S3 bucket or writing to one DynamoDB table.
The common mistake
Putting application permissions on the execution role, or reusing one broad role for both. If the container is compromised, the attacker inherits everything that role can do.
Four quick wins
- One task role per service. Never share a task role across unrelated services.
- Scope to resources. Replace
"Resource": "*"with specific ARNs. - Lock the trust policy. Trust only
ecs-tasks.amazonaws.comand addaws:SourceAccountandaws:SourceArnconditions to prevent confused deputy issues. - Review what is used. IAM Access Analyzer can flag unused permissions and generate a policy from CloudTrail activity.
Takeaway
The execution role gets the task running. The task role is what your code can do. Keep them separate, keep them small, and review them regularly.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article