IAM policies are like layered security badges—one might deny you entry, but you’re in if another gives you an all-access pass. This is AWS IAM Policy Shadowing.
If you’re managing AWS IAM policies, you probably feel pretty confident about your security controls. But what if I told you there’s a hidden risk that could be giving users more access than you intended—without you even realizing it? This journey is as much about me learning as it is about sharing what I find. Let’s explore IAM Policy Shadowing together.
AWS IAM is powerful but complex. With policies layered across users, roles, groups, permission boundaries, service control policies (SCPs), and resource-based policies, it’s easy for one policy to override another in unexpected ways. I’ve started digging into this: when an explicitly denied action still gets allowed or permissions don’t behave the way you expect.
Let’s uncover how IAM Policy Shadowing happens, why it’s a security risk, and what we can do about it.
What is AWS IAM Policy Shadowing?
IAM Policy Shadowing occurs when one policy unintentionally overrides another, creating excessive permissions or ineffective restrictions. This usually happens when multiple policies interact in ways that aren’t immediately obvious. Here are some examples:
- A deny policy in an SCP gets overridden by an allow statement in an IAM policy attached to a user or role.
- A permission boundary is set to restrict an action, but an attached managed policy grants broader access.
- A resource-based policy allows access that an identity-based policy should deny.
- AWS-managed policies grant excessive permissions that override custom least-privilege policies.
At first glance, your IAM policies might look solid, but shadowing can creep in silently. That’s why I’m making this my focus—if it’s tripping me up, I’m sure others are facing it too.
Why is This a Problem?
1. Unintended Privilege Escalation
Policy shadowing can lead to users or services having permissions beyond what was intended. This could allow a developer to delete critical resources, an attacker to escalate privileges, or a misconfigured automation script to make unintended changes.
2. Compliance and Audit Failures
Security frameworks like ISO 27001, SOC2, and NIST require strict access control. Shadowed policies can make it seem like permissions are restricted when, in reality, a different policy might be granting unexpected access.
3. Difficult to Detect and Troubleshoot
AWS IAM policies follow a specific policy evaluation logic (which I’ll dive into in future posts). Shadowing issues aren’t always apparent unless you analyze how multiple policies interact.
Example Scenario: When Policies Clash
Let’s say you apply an SCP at the organizational unit (OU) level to prevent users from deleting S3 buckets:
{
"Effect": "Deny",
"Action": "s3:DeleteBucket",
"Resource": "*"
}
However, an inline IAM policy attached to a developer role includes:
{
"Effect": "Allow",
"Action": "s3:*",
"Resource": "*"
}If the SCP should override all IAM policies, then the delete action should be blocked, right? Not necessarily! Another attached policy could override the deny, allowing deletion depending on where the policies are applied. Understanding the interaction between IAM policies, SCPs, permission boundaries, and resource-based policies is crucial.
What’s Next?
This is just the beginning. Over the next few months, I’ll be:
✅ Exploring how to detect AWS IAM Policy Shadowing using native tools (IAM Access Analyzer, CloudTrail, AWS Config, and third-party tools).
✅ Breaking down AWS IAM Policy Shadowing evaluation logic to understand why shadowing happens.
✅ Showing hands-on examples of fixing policy conflicts with real-world scenarios.
✅ Discussing compliance risks and how to document IAM controls properly.
Join Me on This Learning Journey
If you’ve encountered IAM policies behaving in unexpected ways, let’s talk! Share your experiences, questions, or horror stories—I’d love to hear them. I’ll be posting regularly, and I’ll incorporate your feedback and challenges into upcoming posts.
Stay tuned for next month’s deep dive: How to Detect IAM Policy Shadowing in AWS Using Built-in Tools.
Let’s demystify IAM policies together.
Where to Learn More
- AWS Documentation
- Tools for Policy Analysis
- Blog Posts and Deep Dives
- AWS Security Blog – Best Practices for AWS IAM Policies
- Rhino Security Labs – AWS IAM Security Flaws
- NCC Group Research – AWS IAM Risks and Analysis