Amplify DynamoDB Table's `grantReadWriteData` does not grant permissions on indexes

[fossamagna]

Environment information

System:
  OS: Linux 6.6 Debian GNU/Linux 11 (bullseye) 11 (bullseye)
  CPU: (8) arm64 unknown
  Memory: 18.46 GB / 23.43 GB
  Shell: /bin/bash
Binaries:
  Node: 22.16.0 - /usr/local/bin/node
  Yarn: 1.22.22 - /usr/local/bin/yarn
  npm: 10.9.2 - /usr/local/bin/npm
  pnpm: undefined - undefined
NPM Packages:
  @aws-amplify/auth-construct: 1.8.1
  @aws-amplify/backend: 1.16.1
  @aws-amplify/backend-ai: Not Found
  @aws-amplify/backend-auth: 1.7.1
  @aws-amplify/backend-cli: 1.8.0
  @aws-amplify/backend-data: 1.6.1
  @aws-amplify/backend-deployer: 2.1.3
  @aws-amplify/backend-function: 1.14.1
  @aws-amplify/backend-output-storage: 1.3.1
  @aws-amplify/backend-secret: 1.4.0
  @aws-amplify/backend-storage: 1.4.1
  @aws-amplify/cli-core: 2.2.1
  @aws-amplify/client-config: 1.8.0
  @aws-amplify/data-construct: 1.16.3
  @aws-amplify/data-schema: 1.21.0
  @aws-amplify/deployed-backend-client: 1.8.0
  @aws-amplify/form-generator: 1.2.1
  @aws-amplify/model-generator: 1.2.0
  @aws-amplify/platform-core: 1.10.0
  @aws-amplify/plugin-types: 1.11.0
  @aws-amplify/sandbox: 2.1.2
  @aws-amplify/schema-generator: 1.4.0
  @aws-cdk/toolkit-lib: 1.1.1
  aws-amplify: 6.15.3
  aws-cdk-lib: 2.189.1
  typescript: 5.8.3
No AWS environment variables
No CDK environment variables

Describe the bug

Even when granting permissions using table.grantReadWriteData(grantee), access to GSIs created via secondaryIndexes is not granted to the grantee.

Workaround

Instead of calling table.grantReadWriteData directly, use the following function.

function grantReadWriteData(table: ITable, grantee: IGrantable) {
  return table.grantReadWriteData(grantee).combine(
    Grant.addToPrincipal({
      grantee,
      actions: ["dynamodb:Query", "dynamodb:Scan"],
      resourceArns: [`${table.tableArn}/index/*`],
    }),
  );
}

Reproduction steps

1. Define schema inamplify/data/resource.ts

   export const schema = a.schema({
     Customer: a
       .model({
         name: a.string(),
         phoneNumber: a.phone(),
         accountRepresentativeId: a.id().required(),
       })
       .secondaryIndexes((index) => [index("accountRepresentativeId")])
       .authorization(allow => [allow.publicApiKey()]),
   });

2. Add amplify/functions/getCustomerByAccountRepresentativeId/resource.ts

   import { defineFunction } from '@aws-amplify/backend';
   export const getCustomerByAccountRepresentativeId = defineFunction({
     name: 'getCustomerByAccountRepresentativeId',
   });

3. Add amplify/functions/getCustomerByAccountRepresentativeId/handler.ts

   import type { Handler } from 'aws-lambda';
   
   export const handler: Handler = async (event, context) => {
     // Code for accessing a DynamoDB table using GSI goes here
     ...
   };

4. Lastly, this function needs to be added to your backend.

   import { defineBackend } from '@aws-amplify/backend';
   import { getCustomerByAccountRepresentativeId } from './functions/getCustomerByAccountRepresentativeId/resource';
   
   const backend = defineBackend({
     getCustomerByAccountRepresentativeId
   });
   
   const table = backend.data.resources.tables.Customer;
   table.grantReadWriteData(backend.getCustomerByAccountRepresentativeId);

5. Run npx ampx sandbox
6. Permissions are granted for the Customer table, but not for the indexes.

[pahud]

Hi @fossamagna,

Thank you for the detailed bug report and the workaround! This appears to be a valid issue with how Amplify Backend exposes DynamoDB tables with secondary indexes.

The root cause is that when you access the table via backend.data.resources.tables.Customer, the table reference doesn't properly indicate that it has indexes. This causes the underlying AWS CDK TableGrants class to skip adding the ${tableArn}/index/* resource ARN when granting permissions.

In the CDK's TableGrants implementation, permissions for indexes are only added when the hasIndex property is true:

if (props.hasIndex) {
 this.arns.push(...this.arns.map((arn) => ${arn}/index/*));
}

Your workaround correctly addresses this by manually adding the index permissions using Grant.addToPrincipal().

Recommended Fix:

Should ensure that when tables with secondaryIndexes are exposed via backend.data.resources.tables, they properly indicate the presence of indexes. This could be done by:

1. Setting the hasIndex property correctly on the table reference
2. Using Table.fromTableAttributes() with grantIndexPermissions: true or explicitly listing the index names
3. Overriding the grant methods to include index ARNs

This is similar to an issue that was fixed in AWS CDK back in 2019 (see aws-cdk#1540).

[fossamagna]

HI, @pahud
Thank you for presenting the recommended fix.
I have a few questions.

At the time Table.fromTableAttributes() is called, it is not yet certain whether the index exists. Therefore, I think that it is impossible to determine whether grantIndexPermissions: true should be set.

The index is set at the following location. This occurs after the call to Table.fromTableAttributes().

• https://github.com/aws-amplify/amplify-category-api/blob/3ae3d14a26cc562bfb4995bd6d9032c3d613170e/packages/amplify-graphql-index-transformer/src/resolvers/resolvers.ts#L387-L413
• https://github.com/aws-amplify/amplify-category-api/blob/3ae3d14a26cc562bfb4995bd6d9032c3d613170e/packages/amplify-graphql-relational-transformer/src/resolvers.ts#L185
• https://github.com/aws-amplify/amplify-category-api/blob/3ae3d14a26cc562bfb4995bd6d9032c3d613170e/packages/amplify-graphql-conversation-transformer/src/transformer-steps/conversation-resolver-generator.ts#L324

Overriding the grant methods to include index ARNs

Which class's methods are these grant methods intended for?
I believe it would be difficult to change the implementation of the ITable returned by Table.fromTableAttributes(). Or are you referring to methods in a different class?

[pahud]

Hi @fossamagna,

Let me clarify:

On grantIndexPermissions: true

Yes, indexes are added after Table.fromTableAttributes() is called. However, setting grantIndexPermissions: true doesn't require knowing whether indexes actually exist - it simply tells CDK to always include index ARNs in grant operations.

The behavior is defined in

https://github.com/aws/aws-cdk/blob/b9564923ee1136e7b680115a2983ad317b0c30fb/packages/aws-cdk-lib/aws-dynamodb/lib/table.ts#L1162-L1164

• grantIndexPermissions: true → Always grants permissions for ${tableArn}/index/*
• grantIndexPermissions: false (default) → Never grants permissions for indexes

Since Amplify manages the table lifecycle and users define indexes through the schema, it's safe to always set this to true. The worst case is granting permissions for indexes that don't exist, which is harmless - IAM policies with non-existent resources don't cause errors. I believe this requires a PR and is not something users can immediately unblock themselves.

On overriding grant methods

I should clarify - this is exactly the workaround in your original description.

public grantReadWriteData(grantee: IGrantable): Grant {
 return this.tableFromAttr.grantReadWriteData(grantee).combine(
   Grant.addToPrincipal({
     grantee,
     actions: ['dynamodb:Query', 'dynamodb:Scan'],
     resourceArns: [${this.tableArn}/index/*],
   })
 );
}

---

PoC

import { Grant } from 'aws-cdk-lib/aws-iam';
import type { ITable, IGrantable } from 'aws-cdk-lib/aws-dynamodb';

function grantReadWriteData(table: ITable, grantee: IGrantable) {
  return table.grantReadWriteData(grantee).combine(
    Grant.addToPrincipal({
      grantee,
      actions: ['dynamodb:Query', 'dynamodb:Scan'],
      resourceArns: [`${table.tableArn}/index/*`],
    })
  );
}

// Use it:
const table = backend.data.resources.tables.Customer;
grantReadWriteData(table, backend.myFunction);

Conclusions

• Yes, I believe this would need a PR and probably add grantIndexPermissions: true
• Your workaround is correct.

Let me know if it makes sense to you. Thanks.

[fossamagna]

@pahud
Thanks a lot for explaining everything in such detail. I really appreciate it, and I understand the intent much more clearly now.
So I’ll go ahead and start working on the Pull Request.