Guide · Cybersecurity
How to Restrict IAM Roles Properly
Overly permissive IAM roles create blast radius. Here's how to scope them to minimal permissions.
Broad IAM roles fail Authorization—least privilege for humans, services, and agents. Primary control: Authorization
"Get it working" wildcards become tomorrow's incident
`s3:` on `` and one shared role for every Lambda feel fast until one compromised function can read every bucket. That exact pattern turned a single Lambda breach into an all-S3 event for one startup. Least privilege shrinks blast radius before phishing or a leaked key arrives.
Shape roles the boring way
One role per workload—not one mega-role for "the app." Name actions (`s3:GetObject`, `s3:PutObject`) and ARNs (`arn:aws:s3:::payments-bucket/`). Add conditions (MFA, network, tags) for human assume-role paths. Run IAM Access Analyzer and the policy simulator before you attach anything wide; revisit quarterly and delete unused statements.
Copy-paste tutorial policies without scoping are how `` sneaks into prod.
Authorization as an APRF gate
APRF Authorization expects evidence that identities can't do everything. Pair with the admin-access and least-privilege guides when you're replacing `AdministratorAccess` habits.
Next: Authorization
Open the related pillar specification for mandatory checks, artifacts, and pass conditions. Self-attest is optional.
Related
Frequently asked questions
- How do I restrict IAM roles in AWS?
- Use specific actions (e.g., s3:GetObject) and resource ARNs (e.g., arn:aws:s3:::my-bucket/*). Avoid wildcards. Run IAM Access Analyzer to find issues.
- What is IAM Access Analyzer?
- An AWS tool that identifies overly permissive IAM policies. It finds policies that grant access to resources outside your account or that are too broad.
- Should I use one IAM role for multiple services?
- No. Create separate roles per service. Each service gets only the permissions it needs. This limits blast radius if a key is compromised.