Imported DynamoDB TableV2 with fromTableArn does not get access to indexes with grantFullAccess

[rlbrillband]

Describe the bug

Related to 1540, but with a new caveat. There was previously a bug with granting constructs access to a table, where the policy it created would not grant access to any secondary indexes. This was addressed in PR 1564. Notably, I think this was before TableV2 was introduced.
However I have just found that, when importing with cdk.aws_dynamodb.TableV2.fromTableArn, grantFullAccess still does not give adequate permissions for indexes in that case.

Regression Issue

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

Last Known Working CDK Version

No response

Expected Behavior

grantFullAccess should grant access to any indexes of the table.

Current Behavior

grantFullAccess does not access to any indexes of the table.

Reproduction Steps

1: Create a table with an index in AWS.
2: Import the table into a construct with fromTableArn
3: Do grantFullAccess to a lambda
4: Try to access the index from the lambda - this will fail to due inadequate permissions.

Possible Solution

I presume either:
1 - The ITableV2 created by fromTableArn may not be aware of the indexes on the imported table, so did not add permissions for them.
2 - Since TableV2 is newer than the fix, this may have been a regression. However I have not tested a v1 ITable so I can't confirm this.

Additional Information/Context

The table I imported where I discovered this is a couple of years old, and was originally created in AWS SAM, but that should not prevent this from working.

CDK CLI Version

2.1005.0 (build be378de)

Framework Version

2.181.1

Node.js Version

v20.15.1

OS

Ubuntu 24.04

Language

TypeScript

Language Version

5.6.3

Other information

This is the policy that was added:

{
			"Action": "dynamodb:*",
			"Resource": "arn:aws:dynamodb:eu-west-1:[account]:table/[mytablename]",
			"Effect": "Allow"
}

Notably lacking any permissions for /index

[pahud]

When CDK use a resource using the fromXxx() method, it essentially builds a reference object with attributes on it. It's pretty much like you create a table out of CDK and now you need to reference it in your current CDK stack. In this case, CDK by default won't add or update any resource in this referenced resource.

Now when you grantFullAccess() to lambda, generally there would be an addToPrincipalOrResource() call happening, which essentially first add the identity-based policies when possible and optionally add to the resource-based policy. But dynamodb Table2 is a little bit different.

Root Cause

The issue stems from how hasIndex is determined when importing a table with fromTableArn():

1. When using TableV2.fromTableArn(), it calls TableV2.fromTableAttributes()
2. Inside fromTableAttributes(), a new Import class is created that extends TableBaseV2
3. The hasIndex property is initialized as:

aws-cdk/packages/aws-cdk-lib/aws-dynamodb/lib/table-v2.ts

Lines 448 to 450 in b855978

	protected readonly hasIndex = (attrs.grantIndexPermissions ?? false) ||
	(attrs.globalIndexes ?? []).length > 0 ||
	(attrs.localIndexes ?? []).length > 0;

4. Since no attributes are provided when using fromTableArn() directly, hasIndex defaults to false
5. Later, when grantFullAccess() is called, the permission for indexes (${this.tableArn}/index/*) is NOT added:

aws-cdk/packages/aws-cdk-lib/aws-dynamodb/lib/table-v2-base.ts

Lines 432 to 433 in b855978

	const resourceArns = [this.tableArn];
	this.hasIndex && resourceArns.push(`${this.tableArn}/index/*`);

Affected Code

aws-cdk/packages/aws-cdk-lib/aws-dynamodb/lib/table-v2-base.ts

Lines 426 to 440 in b855978

	private combinedGrant(grantee: IGrantable, options: { keyActions?: string[]; tableActions?: string[]; streamActions?: string[] }) {
	if (options.keyActions && this.encryptionKey) {
	this.encryptionKey.grant(grantee, ...options.keyActions);
	}
	if (options.tableActions) {
	const resourceArns = [this.tableArn];
	this.hasIndex && resourceArns.push(`${this.tableArn}/index/*`);
	return Grant.addToPrincipalOrResource({
	grantee,
	actions: options.tableActions,
	resourceArns,
	resource: this,
	});
	}

Workaround

Explicitly provide the TableAttributesV2 with grantIndexPermissions: true:

TableV2.fromTableAttributes(scope, id, { 
  tableArn: 'arn:aws:dynamodb:region:account:table/name',
  grantIndexPermissions: true 
});

Simple Fix

Modify fromTableArn() to automatically set grantIndexPermissions: true when creating the imported table or simply expose this prop to the surface in a new options object.

Making this a p2 and we welcome PRs.

[rlbrillband]

Thanks for looking at this. Just to clarify - this is not intended behaviour? But it can be circumvented using fromTableAttributes with grantIndexPermissions: true. I will make use of that.
Out of curiosity, do you know why fromTableAttributes is designed not to have access to indexes by default? As a user this was clearly not what I expected (otherwise I wouldn't have considered this a bug). Perhaps there's some ideological motivation for it?

[pahud]

Hi,

I checked the source, the default value of grantIndexPermissions is false, which I am not sure if it makes perfect sense here but from least permission's perspective, I think it's acceptable and we are still allowed to customize it using the fromTableAttributes() method.

aws-cdk/packages/aws-cdk-lib/aws-dynamodb/lib/table-v2.ts

Lines 400 to 402 in 83449bc

	* @default false
	*/
	readonly grantIndexPermissions?: boolean;