Wildcard IAM Permissions

Wildcard IAM permissions are cloud access policies that grant sweeping rights — Action: "*", Resource: "*", or full administrator roles — to users, services, or automation that need only a narrow slice of access. They directly violate the principle of least privilege and turn any compromised credential into a master key.

Why It Happens

Scoping permissions precisely is hard: it requires knowing exactly which API calls a workload makes, and that list changes as the app evolves. When something fails with a permissions error, the quickest unblock is to widen the policy until it works, often all the way to a wildcard. Copy-pasted example policies and "we'll tighten it later" intentions cement the over-grant. Shared roles accumulate permissions over time and rarely lose them.

Why It Hurts

A wildcard policy means a single leaked key, SSRF, or compromised container can do anything the account can do — read every bucket, delete databases, create new admin users, or pivot across the environment. The blast radius of any incident expands from one resource to the whole account. Over-broad permissions also break the separation of duties and fail compliance audits (SOC 2, PCI, CIS benchmarks all flag * policies). Because the grants are invisible until abused, they linger for years.

Warning Signs

• Policies contain "Action": "*" or "Resource": "*".
• Service accounts or CI runners hold administrator or owner roles.
• The same role is reused across many unrelated workloads.
• Access reviews cannot explain why a principal holds a given permission.

Better Alternatives

Apply least privilege: grant only the specific actions on the specific resources a workload needs. Derive the required actions from observed usage — cloud providers offer access analyzers and last-accessed data to right-size policies. Use permission boundaries and service control policies to cap the maximum any role can hold. Prefer short-lived, scoped credentials via workload identity over standing broad grants, and separate roles by function so no single principal is omnipotent.

How to Refactor Out of It

1. Inventory policies and flag every wildcard action and resource, plus all admin-equivalent roles.
2. Use access-analyzer and last-accessed reports to see which permissions are actually used.
3. Replace wildcards with explicit, scoped statements covering only used actions and resources.
4. Add permission boundaries / SCPs to prevent future over-grants.
5. Split shared roles into purpose-specific roles, and remove unused permissions on a schedule.
6. Add IaC policy checks (e.g. policy-as-code) that fail builds containing wildcard grants.