AWS IAM策略中限制表与通配符共存的权限生效疑问

Great question! Mixing specific resources like sampletable with wildcards in IAM policies can feel tricky since the official docs don’t explicitly cover every edge case. Let’s break down how AWS evaluates these permissions using real-world scenarios:

Core IAM Evaluation Rules First #

Before diving into examples, remember two non-negotiable rules that drive all decisions:

• Explicit DENY always takes priority: If any DENY statement matches your request, AWS will reject it—regardless of any ALLOW statements that might also apply.
• ALLOW permissions are additive: If no DENY blocks your request, AWS checks if at least one ALLOW statement matches. If yes, you get the permission; if no ALLOW matches, access is denied by default.

Scenario 1: ALLOW Specific Table + ALLOW Wildcard #

Suppose your policy has both an allow for sampletable and a broader allow using *:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "dynamodb:*",
      "Resource": "arn:aws:dynamodb:us-east-1:123456789012:table/sampletable"
    },
    {
      "Effect": "Allow",
      "Action": "dynamodb:GetItem",
      "Resource": "*"
    }
  ]
}

Result: #

You’ll get full DynamoDB access to sampletable (all operations like PutItem, DeleteItem, etc.), plus GetItem access to every other DynamoDB table in the account. The permissions stack because there’s no DENY to block anything.

Scenario 2: ALLOW Wildcard + DENY Specific Table #

This is a common pattern to grant broad access but block a sensitive table:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "dynamodb:*",
      "Resource": "*"
    },
    {
      "Effect": "Deny",
      "Action": "dynamodb:*",
      "Resource": "arn:aws:dynamodb:us-east-1:123456789012:table/sampletable"
    }
  ]
}

Result: #

You can perform any DynamoDB operation on every table except sampletable. The explicit DENY for sampletable overrides the broad ALLOW wildcard—no exceptions here.

Scenario 3: DENY Wildcard + ALLOW Specific Table #

This is a restrictive pattern where you block everything except one table:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": "dynamodb:*",
      "Resource": "*"
    },
    {
      "Effect": "Allow",
      "Action": "dynamodb:GetItem",
      "Resource": "arn:aws:dynamodb:us-east-1:123456789012:table/sampletable"
    }
  ]
}

Result: #

You cannot access sampletable (or any other table). The DENY wildcard matches every possible DynamoDB request (including your GetItem on sampletable), so AWS rejects it immediately—ignoring the ALLOW statement entirely.

Bonus: Mixed Resources in a Single Statement #

If you list both sampletable and * in the same ALLOW statement’s Resource array:

{
  "Effect": "Allow",
  "Action": "dynamodb:GetItem",
  "Resource": [
    "arn:aws:dynamodb:us-east-1:123456789012:table/sampletable",
    "*"
  ]
}

This works exactly like having two separate ALLOW statements—it’s just a shorter way to write the same additive permission. You’ll get GetItem access to sampletable and all other tables.

内容的提问来源于stack exchange，提问作者RajDev