AWS IAM Policy Validator & Analyzer

Deny wins, then allow, then deny again

Evaluation starts from an implicit deny: with no policy at all, nothing is permitted. An explicit Allow anywhere flips that. An explicit Deny anywhere flips it back, permanently: there is no policy that can override a Deny, no matter how specific or how privileged the principal. This is what makes a Deny in a service control policy or a permissions boundary an absolute ceiling.

1. explicit Deny        -> denied, and nothing can override it
2. explicit Allow       -> allowed, if no Deny matched
3. nothing matched      -> denied (the implicit default)

specificity is irrelevant: a Deny on * beats an Allow on an exact ARN

The parts of a statement

Effect is Allow or Deny. Action is what can be done, Resource is what it can be done to, and Principal is who can do it: present in resource policies, absent in identity policies where the principal is whoever the policy is attached to. Condition narrows the whole statement and is the only part that can make a wildcard safe.

{
  "Effect": "Allow",
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::my-bucket/*",
  "Condition": {
    "Bool": { "aws:SecureTransport": "true" }
  }
}

Identity policies and resource policies are different questions

An identity policy is attached to a user, group or role and says what that principal may do. A resource policy is attached to the thing itself: a bucket, a queue, a KMS key, and says who may touch it. Within one account, an Allow in either is usually enough. Across accounts you need both: the resource policy in the owning account and an identity policy in the calling one. A trust policy is a resource policy on a role, which is why it has a Principal and no Resource.

Why a wildcard is worse than it looks

Action: "*" with Resource: "*" is administrator access however it is labelled. Less obvious is that s3:* includes s3:PutBucketPolicy, which lets the holder rewrite the very policy restricting them, and that iam:PassRole without a Resource constraint lets someone attach any role to a service they can launch, which is a straight path to privilege escalation. Those are the patterns worth finding before they ship, and what the analyzer above grades.

"Action": "iam:PassRole", "Resource": "*"

  lets the holder pass the admin role to a new EC2 instance
  and read credentials from the instance metadata endpoint