Permissions follow your connections — every direction, every canvas

When you connect a function to a bucket, a service to a queue, or a state machine to the Lambdas it runs, CloudStack Canvas grants the permissions that connection needs. As of today, those grants are computed from the connections themselves at export time — which means they no longer depend on which direction you drew the arrow, whether you placed an IAM role node yourself or let the canvas create one, or how the canvas came to be: drawn by hand, started from a template, imported from CloudFormation, Terraform, or a draw.io diagram, or generated with AI. Same connections, same permissions, every time.

One more connection gained a choice of meaning. A bucket-to-function connection can mean "this bucket triggers the function" or "this function reads and writes the bucket" — and those need different permissions. The canvas reads your arrow direction as the default (bucket → function is a trigger; function → bucket is access), so nothing changes about how you draw — and you can override the meaning from the connection's label, the same way queue, table, topic, and stream connections already work.

Step Functions state machines drawn without an execution role now get one automatically — with permission to invoke every function you've connected — instead of a placeholder that needed filling in by hand.

Fixes & improvements

• •The findings panel's permission warnings now describe exactly what the export will generate: no more warnings about grants that are in fact present, and a clear nudge when a connection's meaning still needs choosing before its permissions can be generated.
• •Permission guides updated to match, including the Step Functions, ECS, and secrets guides.
• •A Redshift-to-role connection could previously write an overly broad S3 grant onto the role; that connection now wires without granting anything the cluster's own role doesn't already scope precisely.