An ECS Service is connected to more than one IAM Role node (a common shape: one "execution role" plus one "task role"). CloudStack Canvas cannot tell which one your running container code should assume, so it deliberately does NOT guess — it self-mints its own Task Role instead, and neither of your connected roles' permissions reach the running task. Connect your intended task role directly to the Task Definition node instead — that connection is unambiguous and always wins.
Paste into this field
No field to fill — reconnect an edge on the canvasOutput looks like
Canvas edge: IAM Role ("Task Role") → ECS Task DefinitionOn the canvas, find the IAM Role node that holds the permissions your APPLICATION code needs at runtime (S3, SQS, Secrets Manager, etc.) — not the one that only has AmazonECSTaskExecutionRolePolicy (that one is the execution role, used for ECR pull + CloudWatch logs).
Hover over that IAM Role node until connection handles appear. Drag from the Role to your ECS Task Definition node (not the Service). Release to create the edge. Make sure that role already has an ecs-tasks.amazonaws.com trust policy first (the auto-created "ECS Task Role" companion does, by default) — a role connected directly to a Task Definition is NOT trust-checked the way the Service-level fallback is, so a wrong-trust role connected this way would still break every RunTask. CloudStack Canvas will warn you separately if it detects that.
The Task Definition connection now takes priority regardless of what is still connected to the Service — you can leave the Service→Role edges in place for documentation, or remove them to reduce clutter.
Re-open Export. The "connected to N IAM Role nodes" warning should be gone.
Once you have the value, go back to CloudStack Canvas and paste it into the highlighted field.
CloudStack Canvas · Validation Guide