ECS Task IAM Least Privilege for n8n
n8n workflows can call AWS APIs in two very different ways. They can use credentials stored inside n8n, or they can use the IAM role attached to the ECS task. The second option is powerful because it avoids static keys, but it also creates a large blast radius if the task role is too broad.
Least privilege for n8n on ECS starts by separating what the platform needs from what each workflow wants.
Context
Problem: A broad ECS task role can turn workflow compromise into broad AWS access. Approach: Assign narrow task roles by workflow class and keep the execution role separate from runtime permissions. Outcome: n8n can use AWS APIs without handing every workflow the same cloud privileges.
Role separation
Use distinct roles:
- Task execution role: pull images, write logs, retrieve startup secrets.
- Runtime task role: permissions available to the running container.
- Deployment role: register task definitions and update services.
- Break-glass role: tightly controlled emergency operations.
The execution role should not become a general application role. Its job is to let ECS start the task.
Workflow classes
Group workflows by AWS impact:
- Read-only enrichment.
- Ticketing and notification.
- Security finding triage.
- Quarantine or containment.
- Identity or access changes.
- Infrastructure changes.
If one workflow class needs securityhub:BatchUpdateFindings, that does not mean all n8n workers should have it.
ECS service pattern
Run separate worker services for high-risk action classes:
1
2
3
n8n-worker-enrichment -> read-only task role
n8n-worker-ticketing -> ticketing integration role
n8n-worker-response -> tightly scoped response role
Route workflows to the appropriate worker pool where the n8n deployment model supports it. If that separation is not available, reduce the task role and use explicit credentials or external approval services for privileged actions.
Detection and review
Review CloudTrail for:
- New AWS API actions from n8n task roles.
- Calls outside normal regions or accounts.
- Secrets Manager access by runtime roles.
- IAM policy changes near workflow releases.
- Failed access denied events that indicate permission probing or drift.
Access denied events are useful. They show where workflows tried to cross a boundary.
Takeaways
The ECS task role is a security boundary for n8n. Keep it narrow, separate it from the execution role, and avoid giving every workflow the permissions needed by the most privileged automation path.