DynamoDB + IAM Policies: Preventing Accidental Public Access

Question

DynamoDB + IAM Policies: Preventing Accidental Public Access
When a table is shared via an IAM policy that uses a wildcard resource ARN, any principal with permission to the broader resource can read or write the table, even if the intention was to restrict access to a specific account or service. A VPC interface endpoint can keep traffic inside a VPC, but it does not override a permissive IAM policy. Adding a customer‑managed CMK introduces another layer: the KMS key policy must grant the DynamoDB service principal and any cross‑account principals that need to access the table. The documentation does not explicitly state whether the KMS key policy must also allow a cross‑account principal when the table is shared through a resource‑based policy, leading to inconsistent access outcomes.
Given these overlapping controls, what is the safest combination of IAM, VPC endpoint, and KMS key policies that guarantees a table cannot be accessed by unintended principals?
1. Does a VPC endpoint automatically deny access for principals that are not explicitly allowed in the endpoint policy?
2. When a table is shared cross‑account via a resource‑based policy, must the KMS key policy also grant the cross‑account principal access to the CMK?
3. If a customer‑managed CMK is used, what is the minimal set of permissions required on the KMS key policy to allow DynamoDB to read and write the table while preventing other principals from doing so?

Tasadduq Burney · Answer

Confirmed facts
IAM policies can explicitly deny DynamoDB actions when the request does not come from an allowed source using condition keys such as aws:SourceVpce, aws:SourceIp or aws:VpcSourceIp. A VPC endpoint does not automatically deny traffic; the endpoint policy must contain an explicit deny for any action not permitted. When a table is encrypted with a customer‑managed CMK, the KMS key policy must grant the DynamoDB service principal (dynamodb.amazonaws.com) permission to use the key for encrypt/decrypt operations. If the table is shared cross‑account via a resource‑based policy, the external account’s principal must also be allowed in the KMS key policy to use the CMK.
Likely explanation of accidental public access
Accidental exposure usually occurs when a broad IAM policy (e.g., AdministratorAccess) or a missing resource‑level condition allows any AWS credential holder to call DynamoDB APIs. Even if a VPC endpoint is used, a permissive IAM policy or an overly permissive endpoint policy can still let unintended principals reach the table.
Steps to guarantee the table cannot be accessed by unintended principals

Identify the DynamoDB table ARN(s) you want to protect (e.g., arn:aws:dynamodb:us-east-1:123456789012:table/MyTable).
  Create an IAM policy that denies all DynamoDB actions on those resources unless the request originates from an approved source:
    {
    "Version": "2012-10-17",
    "Statement": [
      {
        "Effect": "Deny",
        "Action": "dynamodb:*",
        "Resource": "arn:aws:dynamodb:us-east-1:123456789012:table/MyTable",
        "Condition": {
          "StringNotEquals": {
            "aws:SourceVpce": "vpce-0abcd1234efgh5678"   
          }
        }
      }
    ]
  }
  
    If your traffic comes from the public internet, replace the condition with aws:SourceIp and list your allowed CIDR blocks.
  
  Attach this deny policy to every IAM role, user, or group that needs table access. Remove any broader permissive policies (e.g., AmazonDynamoDBFullAccess) from those principals.
  Configure the VPC endpoint policy to allow only the specific DynamoDB actions required by your application and deny everything else. Example minimal allow list:
    {
    "Version": "2012-10-17",
    "Statement": [
      {
        "Effect": "Allow",
        "Principal": "*",
        "Action": [
          "dynamodb:GetItem",
          "dynamodb:PutItem",
          "dynamodb:UpdateItem",
          "dynamodb:DeleteItem",
          "dynamodb:Query",
          "dynamodb:Scan"
        ],
        "Resource": "arn:aws:dynamodb:us-east-1:123456789012:table/MyTable"
      },
      {
        "Effect": "Deny",
        "Principal": "*",
        "Action": "dynamodb:*",
        "Resource": "*"
      }
    ]
  }

Create a customer‑managed CMK for DynamoDB encryption. In the key policy, grant the DynamoDB service principal the minimum KMS permissions needed to encrypt and decrypt table data:
    {
    "Version": "2012-10-17",
    "Id": "key-dynamodb-policy",
    "Statement": [
      {
        "Sid": "Allow DynamoDB service use",
        "Effect": "Allow",
        "Principal": {
          "Service": "dynamodb.amazonaws.com"
        },
        "Action": [
          "kms:Encrypt",
          "kms:Decrypt",
          "kms:ReEncrypt*",
          "kms:GenerateDataKey*",
          "kms:DescribeKey"
        ],
        "Resource": "*"
      }
    ]
  }
  
    If the table is shared cross‑account via a resource‑based policy, add another statement that allows the external account’s role or user (or the account root) the same KMS actions:
  Ensure no other IAM or KMS policies grant broader DynamoDB or KMS permissions that could override the denies.

Missing diagnostic detail
To finalize the condition in the IAM deny policy, please confirm whether your application accesses DynamoDB from within a VPC (use aws:SourceVpce) or from the public internet (use aws:SourceIp). This determines which condition key to use and does not change the overall approach otherwise.

DynamoDB + IAM Policies: Preventing Accidental Public Access

DynamoDB + IAM Policies: Preventing Accidental Public Access

1 answer

Confirmed facts

Likely explanation of accidental public access

Steps to guarantee the table cannot be accessed by unintended principals

Missing diagnostic detail

Your perspective belongs here.

1 question comment