DynamoDB Table construct started creating invalid resource-based policy with service principals after v2.222.0

[fneqcf]

Describe the bug

After upgrading aws-cdk-lib from v2.207.0 to v2.222.0+, a DynamoDB Table construct started creating resource-based policies that include service principals, this caused the deployment to fail

Versions tested

• v2.220.0: No issues
• v2.222.0: Build fails with dependency cycle error: "Template is undeployable, these resources have a dependency cycle"
• v2.234.1: Dependency cycle resolved, but deployment fails with: Resource handler returned message: "One or more parameter values were invalid: Invalid policy document: Policy contains invalid service principal (Service: DynamoDb, Status Code: 400)"

Possibly related PRs

• feat(core): IEnvironmentAware interface to retrieve a construct's environment #35817
• fix(dynamodb): addToResourcePolicy has no effect #35554

Regression Issue

• Select this option if this issue appears to be a regression.

Last Known Working CDK Library Version

v2.220.0

Expected Behavior

DynamoDB Table construct should not generate resource-based policies with invalid service principals after upgrading CDK versions

Current Behavior

The synthesized template includes an invalid service principal in the DDB resource-based policy, it caused cfn deployment to fail.

Reproduction Steps

1. Create a DynamoDB Table with grantReadWriteData using a ServicePrincipal:

const table = new Table(this, 'MyTable', {
   tableName: 'my-table',
   partitionKey: {
       name: 'pk',
       type: AttributeType.STRING,
   },
   sortKey: {
       name: 'sk',
       type: AttributeType.STRING,
   },
   encryption: TableEncryption.CUSTOMER_MANAGED,
   billingMode: BillingMode.PAY_PER_REQUEST,
   removalPolicy: RemovalPolicy.RETAIN,
   pointInTimeRecovery: true,
});

table.grantReadWriteData(new ServicePrincipal('myservice.amazonaws.com'));

2. deploy with aws-cdk-lib v2.222.0 or later.

Possible Solution

No response

Additional Information/Context

No response

AWS CDK Library version (aws-cdk-lib)

2.222.0

AWS CDK CLI version

2.1030.0

Node.js Version

v20.18.3

OS

macOS 15.7.4

Language

TypeScript

Language Version

No response

Other information

No response

[pahud]

Hi @fneqcf,

┌──────────────────────────────────────────────────────────┐
│ 🔴 Reported State                                        │
│ grantReadWriteData(ServicePrincipal) creates invalid     │
│ DynamoDB resource policy after v2.222.0                  │
└────────────────────────────┬─────────────────────────────┘
                             │
                             ▼
┌──────────────────────────────────────────────────────────┐
│ 🔍 Root Cause                                            │
│ Grant.addToPrincipalOrResource falls through to          │
│ addToResourcePolicy for ServicePrincipals, but DDB       │
│ resource policies don't support service principals       │
│ (grant.ts L148-183 + default-traits.ts L58-74)           │
└────────────────────────────┬─────────────────────────────┘
                             │
                             ▼
┌──────────────────────────────────────────────────────────┐
│ 🟢 Suggested Fix                                         │
│ Validate principal types in DynamoDB's                   │
│ addToResourcePolicy and reject service principals        │
└──────────────────────────────────────────────────────────┘

I was able to reproduce this locally on the current main branch. Calling table.grantReadWriteData(new ServicePrincipal(...)) synthesizes a DynamoDB resource policy containing a service principal, which DynamoDB rejects at deploy time.

This is a regression introduced by the combination of two PRs merged in v2.222.0:

1. #35554 fixed addToResourcePolicy so it actually takes effect (previously it was silently dropped).
2. #35817 introduced the IResourceWithPolicyV2 trait system, which enabled the grant framework to automatically discover and use DynamoDB resource policies.

The grant logic in Grant.addToPrincipalOrResource() correctly identifies that a ServicePrincipal has no account and falls through to add a resource policy — this works for S3 and KMS which support service principals, but DynamoDB resource-based policies only support AWS account principals and IAM principals.

In my opinion, the fix should be in DynamoDB's CfnTableWithPolicy.addToResourcePolicy() to validate that the statement's principals are supported by DynamoDB before adding them. Statements with unsupported principal types (like service principals) should return { statementAdded: false }.

[otaviomacedo]

@fneqcf are you creating a table and calling some grant method on that table, directly from your application? Or is it some other construct that is making that call?

[kumsmrit]

@fneqcf
Thank you for reporting the issue.
This is an issue introduced on CDK side. Before v2.222.0, addToResourcePolicy on DynamoDB tables was a no-op (#35062), so calling grantReadWriteData(new ServicePrincipal(...)) did not generated a resource policy. But, after the fix in #35554, the grant framework now falls through to addToResourcePolicy for service principals (since they have no identity policy to attach to), producing a resource policy.

Before we add a fix, we need to clarify the intended behavior with the DynamoDB service team. The general DynamoDB resource policy docs describe policies in terms of IAM principals, but don't explicitly state service principals are unsupported.
In fact, some service principals are documented as valid in specific scenarios; for example:

• replication.dynamodb.amazonaws.com for multi-account global tables: https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/globaltables_MA_security.html
• redshift.amazonaws.com for the Redshift zero-ETL integration: https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/RedshiftforDynamoDB-zero-etl.html

We tested deploying with these supported service principals and they work:

const table = new Table(this, 'MyTableRegression', {
      tableName: 'my-table-regression',
      partitionKey: { name: 'pk', type: AttributeType.STRING },
      sortKey: { name: 'sk', type: AttributeType.STRING },
      encryption: TableEncryption.CUSTOMER_MANAGED,
      billingMode: BillingMode.PAY_PER_REQUEST,
      removalPolicy: cdk.RemovalPolicy.RETAIN,
      pointInTimeRecovery: true,
    });
    table.grantReadWriteData(new ServicePrincipal('redshift.amazonaws.com'));

Based on these, there isn't a blanket restriction- DynamoDB appears to allow specific service principals.
We will check with the DynamoDB service team to clarify if only specific service principals are supported and based on that we will add the appropriate fix in CDK.