Over-Permissive IAM

What Is Over-Permissive IAM?

An IAM policy grants what it says, not what the role's name suggests. A policy allowing every action on every resource, attached to something called a build agent, is an administrator credential with a boring name. You'll read the wildcard policy on a low-value-looking credential and use iam:PassRole to hand a privileged role to a function you create and invoke. The caller never holds the admin permission directly, which is why that escalation survives review. Then you'll enumerate actions on named resources and attach a permission boundary.

What You'll Learn in Over-Permissive IAM

• A wildcard policy grants what it says, not what the role's name suggests. A boring name does not limit a broad grant.
• Role-passing is a common escalation path because the caller never holds the privileged permission directly, which makes it easy to miss in review.
• Replace wildcards with enumerated actions on named resources. A deny list defaults every new resource to allowed.
• A permission boundary caps what the role can ever hold, so a future policy edit cannot re-grant the escalation.

Over-Permissive IAM — Training Steps

1. A boring set of keys

   Bob is working Wyndlar, a freight brokerage that moves several hundred million pounds of carrier settlements a year. What he has is unglamorous: one credential belonging to a build agent, lifted from a pipeline log. A build agent packages artifacts. On paper this is nearly worthless. He checks what it actually is before deciding that.

2. What it is allowed to do

   The only way to know a role's reach is to read the policy attached to it. Bob reads it.

3. What else is in the account

   A wildcard means Bob can look at everything, so he looks at the roles. He is not after the build agent's own reach. He is after something the build agent can point at.

4. Hand the privileged role to something that will run it

   This is the escalation, and it is worth being precise about why it works. Bob never assumes the admin role himself and never needs to. He creates a function and tells the platform to run it as the admin role. The platform is trusted; he is not; the result is the same.

5. What the admin role could see

   The function is his code running with someone else's authority. He invokes it.

6. Why the name did not matter

   Bob has an administrator's reach from a credential nobody would have bothered to protect.

7. A function nobody created

   Wyndlar's platform review flags a function that appeared overnight carrying the break-glass role.

8. Read what the role is actually allowed

   The answer is not in the function. It is in the policy on the role that created it.

9. The build agent

   Three roles, and one of them is flagged.

10. Everything, on everything

    There it is, in one statement.