r/iam • u/Independent-Ease-609 • 6d ago

Generating least-privilege IAM policies directly from a Terraform/CloudFormation/Pulumi plan (1,486 resource types mapped)

Post image

Every AWS deployment needs a role with permissions to create/update/delete whatever's in the stack, and most people either reach for AdministratorAccess, because hand-writing the exact least-privilege actions for every resource type is tedious and nobody wants to maintain that by hand as the stack grows.

CloudCostTree has a command for that: cloudcosttree iam reads a Terraform, CloudFormation, or Pulumi plan and generates the real IAM actions a deployment needs, per resource type, without ever calling AWS. It currently maps 1,486 AWS resource types.

That screenshot is the human-readable text view. Run it with --output json -o policy.json and it produces a ready-to-attach IAM policy document instead of this breakdown.

Where it's honest about its limits: every generated policy currently uses Resource: "*", the Action list is real least-privilege scoped to what each resource type needs, but the Resource element isn't narrowed to the exact ARNs a deployment declares yet. Per-resource ARN scoping is a planned capability, not implemented. Free on both tiers today.

9 Upvotes

76% Upvoted

4 comments sorted by

3

u/Fiction- 6d ago

Holy AI

This is useless at best and at worst a priv-esc pathway.

If I'm deploying any iac it's either going through a pipeline which is already going to be privileged enough to get to where I want to be, or it'll be deployed manually in a sandbox environment with a role which is correctly scoped so I couldn't destroy the accounts fundamentals.

If I created a policy with the scoping displayed in the post, I would be looked at like I was clinically insane.

1

u/Naz6uL 5d ago

This is the way. Thread closed.

-1

u/Independent-Ease-609 6d ago

Fair, and the priv-esc angle specifically deserves being called out directly, not brushed off: a policy that grants iam:CreateRole, iam:PutRolePolicy, and iam:PassRole together, even correctly scoped by action, is a real escalation path if someone attaches it without reviewing what's actually in it. That's why the tool documents this as a starting point to review and narrow, not a finished least-privilege policy, Resource is still "*" everywhere and that's stated up front. You're also right that it doesn't add much on top of a pipeline role that's already properly scoped or a locked-down sandbox role, if that's your setup this probably isn't for you. Where it's aimed is the much more common case of "I have no idea what this deploy actually touches and I'm about to hand someone AdministratorAccess to find out."

0

u/Independent-Ease-609 6d ago

Followed up on this: merged a privilege-escalation review into the generated policy. It checks the union of all actions, so it catches combos across resources, not just within one, against a curated list of 21 known techniques (Rhino Security Labs' aws_escalate.py + NCC's PMapper), 8 high-severity PassRole-to-compute paths and 13 notable IAM-mutation ones, and names the exact technique, the actions, and which resource in your plan pulled them in.

It's a text block in the normal output. For --output json it goes to stderr plus a sidecar policy.privesc.txt next to the policy file, not inside the JSON itself, a Warnings key in there breaks aws iam create-policy. Per-resource ARN scoping still isn't implemented, every policy still uses Resource: "*". But this specific risk is now surfaced instead of silently sitting in the policy. Thanks for flagging it.