aws-apigateway: missing permission when adding nested resource on imported REST API Gateway backed by Lambda

[rodrigomata]

Describe the bug

Given a REST API Gateway stack that is constructed separately and then imported via LambdaRestApi.fromRestApiAttributes, if the resource specified on the attribute is not the root resource, and after creating a method and resource on the imported one, it will create wrong permissions for the lambda, as the sourceArn won't match anymore.

Expected Behavior

If the resource created is at the root level, it won't have any issues, since the created permission will be something like /*/<method>/resource; however, let's say that we have a base/root resource like /v1 which we create in the main REST API Gateway stack (StackA), and then we create another stack (StackB) importing resources from the main stack (StackA) and we want a GET resource with /users but to live below /v1 so that the end result would be something like /v1/users. The lambda function should have the permissions like /*/GET/v1/users.

Current Behavior

By using the expected behavior example, the actual behavior is that the resulting permission turns to be /*/GET/users, which is wrong and results into the request be denied because of permissions.

Reproduction Steps

1. Create a RestApi stack (StackA) with root resource (eg. /v1)

const api = new RestApi(this, 'sample-api');

const base = api.root.addResource('v1');
base.addMethod('GET');

new CfnOutput(this, 'sample-api-id', { value: api.restApiId, exportName: 'api:id' })
new CfnOutput(this, 'sample-resource-id', { value: base.resourceId, exportName: 'resource:id' })

2. Create another stack (StackB) by importing restApiId and resourceId from v1 resource (instead of restApiRootResourceId that would point to the root resource) from StackA and using them to import RestApi with the method fromRestApiAttributes

const nestedApi = RestApi.fromRestApiAttributes(this, 'nested-api', { 
  restApiId: Fn.importValue('api:id'),
  rootResourceId: Fn.importValue('resource:id'),
})

3. Inside StackB create method and resource (eg. users)

const integration = new LambdaIntegration(handlerFn);
nestedApi.root.addResource('users').addMethod('GET', integration);

5. Deploy

Possible Solution

I've found two possible workarounds for the issue, both involving adding a new Permission to the lambda integration:

1. Use a wildcard:

declare const handler: lambda.Function;
declare const importedRestApi: apigateway.IRestApi;

handler.addPermission('wildcard-solution', {
  principal: new ServicePrincipal('apigateway.amazonaws.com'),
  sourceArn: importedRestApi.arnForExecuteApi('GET', '*') // Will translate into something like `/*/GET/*`
})

2. Build manually according to the path (will require previous knowledge of the full path before):

declare const handler: lambda.Function;
declare const importedRestApi: apigateway.IRestApi;

handler.addPermission('manual-solution', {
  principal: new ServicePrincipal('apigateway.amazonaws.com'),
  sourceArn: importedRestApi.arnForExecuteApi('GET', '/v1/users') // Will translate into something like `/*/GET/v1/users`
})

Additional Information/Context

By using the workaround, the stack creates two zombie triggers that are unusable:

CDK CLI Version

2.63.0

Framework Version

No response

Node.js Version

16.18.1

OS

MacOS

Language

Typescript

Language Version

No response

Other information

No response

[pahud]

If you export api.restApiId and base.resourceId from stackA to stackB, I don't think stackB will have enough information about the v1 resource so yeah I am afraid you will need to addPermission manually for the handler.

[pahud]

Moving this to discussion as this doesn't seem to be a relevant bug or feature request.

[rodrigomata]

I didn't get why this is not a bug since it's creating unused and wrong triggers and instead a manual solution is required

[Yehonal]

I totally agree with @rodrigomata

I struggled for days on it, trying to fix the existing triggers... and now, after a long research, I ended up here to discover that we need to patch-fix it and that it is normal to have 2 broken triggers for each endpoint.

Is sharing gateway resources between stacks not recommended? I'm trying to implement a versioned URL shared resource (v2/serviceA , v2/serviceB)

UPDATE:

This approach fixes it #21623 (comment)

the concept is that by using fromResourceAttributes instead of fromRestApiAttributes, the shared resource is imported with the information of the path (in my case /v2) in this way the LambdaIntegration can generate permissions properly