Catching Risky IAM in CloudFormation Templates Before You Deploy

Most IAM security conversations center on the AWS console or raw JSON policy documents. But a significant share of production IAM misconfigurations originates in CloudFormation templates. By the time a CF stack is deployed, the IAM roles and policies inside it are live — and unless you reviewed the template before running cdk deploy or aws cloudformation create-stack, you may not have noticed what you just granted.

Why CloudFormation IAM Risk Is Different

In a CloudFormation template, IAM roles are buried alongside compute resources, storage buckets, and networking config. Reviewers focused on architecture often skim past the Properties.Policies block on a Lambda execution role.

A single CloudFormation template may create five roles, two managed policy attachments, and three inline policies — all in a single deploy. The blast radius of an overly-permissive role is multiplied by every resource that role is attached to.

The Most Common CF IAM Mistakes

AdministratorAccess on Lambda execution roles. It is tempting to attach AdministratorAccess during development. That policy grants Action: on Resource: . If the template ships to production unchanged, the function — and anyone who can invoke it — effectively holds root-level access.

Missing permission boundaries on auto-created roles. CloudFormation stacks that create roles often omit permission boundaries. Without a boundary, any policy attached to that role later is unconstrained.

Action: * in inline policies. Inline policies defined inside an AWS::IAM::Role resource are easy to overlook. A wildcard action block in an inline policy grants the same scope as a standalone admin policy.

Wildcard Resource on DynamoDB and S3. Scoping actions correctly but leaving Resource: * means those actions apply to every table or bucket in the account.

How CDK Makes It Easier to Slip Up

CDK provides escape hatches — addToRolePolicy, addOverride, raw PolicyStatement objects — that let developers bypass guardrails. A single escape-hatch call can inject an Action: * statement into an otherwise well-scoped role, and nothing in the CDK build output will flag it.

Catching It Before Deploy

Static analysis of the template. Analyze the raw CloudFormation YAML or JSON — either authored template or CDK-synthesized output from cdk synth — before any deploy command runs.

Policy review gates in CI. Add a template analysis step to your CI pipeline that runs on every pull request touching infrastructure files. Fail the pipeline if a critical IAM finding is present.

Originally published at shieldly.io/blog. Analyze CF templates at shieldly.io/app/iam.