DynamoDB resource-based policy: wildcard Principal with Condition keys – precedence uncertainty

Answer to the Core Questions

1. Does a Principal: "*" with an aws:PrincipalOrgID condition actually limit access?

Yes. The statement is treated as a conditional Allow. It is only applied when the condition evaluates to true. If the calling principal’s organization ID does not match the value in the Condition block, the statement is ignored and does not grant a blanket permission.

2. Does an explicit Deny in a DynamoDB resource policy always override an Allow in an identity‑based policy, even with a wildcard principal?

Yes. AWS follows a global “deny‑overrides‑allow” rule. An explicit Deny in any policy (resource‑ or identity‑based) takes precedence over all Allow statements, regardless of the principal or condition used.

3. Recommended pattern to guard against accidental public exposure

• Use Principal: "*" only when you also provide a condition that evaluates to true for the intended principals.
• Add an explicit Deny that blocks all principals whose aws:PrincipalOrgID does not match the target organization. Example:

• {
    "Sid": "DenyNonOrg",
    "Effect": "Deny",
    "Principal": "*",
    "Action": "dynamodb:*",
    "Resource": "arn:aws:dynamodb:region:account-id:table/TableName",
    "Condition": {
      "StringNotEquals": {
        "aws:PrincipalOrgID": "o-xxxxxxxxxx"
      }
    }
  }

• If the condition key is omitted or misconfigured, the statement defaults to an implicit deny for that request. However, without a deny guard, other Allow statements could still expose the table.

Practical Verification Steps

1. Create a test table in account A and attach a resource‑based policy with Principal: "*" and a Condition on aws:PrincipalOrgID.
2. From account B (different organization), use the IAM Policy Simulator to attempt a dynamodb:GetItem on the table. The simulator should return AccessDenied.
3. In account A, add an explicit Deny statement that blocks all principals not in the target org. Re‑run the simulation; the result remains denied, confirming the deny overrides any allow.
4. Remove the Condition block from the allow statement and repeat the simulation; the request from account B will now succeed, illustrating the importance of the condition.

Key Takeaways

• The Condition on a wildcard principal is evaluated as part of the statement; it does not create a global allow.
• Explicit Deny statements always win over Allow statements in any policy.
• Always pair a wildcard principal with a restrictive condition and, optionally, a hard deny to guard against misconfiguration.