DynamoDB + IAM Policies: Preventing Accidental Public Access

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?