apigatewayv2: incorrect arn function causing unwanted behavior #33218
Comments
IkeNefcy
added
bug
github-actions
bot
added
the
@aws-cdk/aws-apigatewayv2
|
Hi, This makes sense to me and thank you for your detailed feedback.
Are you able to share the full error messages? I checked the document and found this And I agree this should be avoided. Thank you for your PR. |
pahud
added
p1
and removed
needs-triage
|
It's simply an access denied, I'll get the API-G log |
|
|
If I build my websocket app with vite and test connecting, the console outputs that it cannot connect. |
|
I scanned the document you sent and oddly I don't see any mention of this behavior, perhaps something that could be added / clarified. The closest match is |
|
The log is very helpful. I'll bring this up to the team for visibility. Please feel free to continue your PR. The team would review your PR when it's ready. |
…33100) fixes: #33218 ### Reason for this change In websocket APIs in `aws-apigatewayv2`, the function arnForExecuteApi has essentially the same exact functionality as a REST API, which is not appropriate for Websockets which are fundamentally different. The way I found this issue was I used arnForExecuteApi to put the arn of the api into an IAM Role. The reason for this was because I was trying to use an IAM authorizer, which from a React standpoint meant signing iam credentials from my Cognito id pool using Amplify lib. When doing this I used arnForExecuteApi from CDK to write the policy, I did not include any arguments, just the default. The issue was that this was not working. I spent time diving deep on the issue in case it was the method in which I was signing the credentials, since I was not too familiar with this process. I also got the assistance of a Cloud Support Engineer from AWS to try and identify the problem. Shout-out Mike Sacks. The problem ended up being that that the resource policy was not correct. The policy that was generated by the function arnForExecuteApi was ``` "Resource": "arn:aws:execute-api:us-east-1:acc:apiId/*/*/*", ``` This is because the function itself has 3 values, stage, method and path, so when all are left in default states, this indicates `all` or `*`. So when adding each value at default you get `/*/*/*`, 3 x /*. This is an issue because Websocket arns are not structured like this, and as it turns out **iam prevents access if you have too many wild cards than applicable**. This means the reason for getting access denied was not because of my signed url, but because having 1 extra /* means that you no longer have permissions. Websocket arns are structured like this ``` arn:aws:execute-api:us-east-1:acc:apiId/*/$connect ``` In this example, * is the stage (this is what it shows on the console) and $connect is the `route`. You can add as many routes as you want, but the main ones by default are $connect, $disconnect and $default for no matching route. So if I want to grant an IAM role to have access to all routes and all stages, I would use this: ``` "Resource": "arn:aws:execute-api:us-east-1:acc:apiId/*/*", ``` Note 2 x /* instead of 3. Simply changing this by hand (deleting 2 characters) was enough to get the websocket to begin connecting via my signed url. ### Description of changes A re-write of the function for creating the arn. This is implemented as arnForExecuteApiV2, the original function has been changes to include the deprecated tag. This is to avoid making a breaking change since the new function only has 2 args and the original had 3. ```ts /** * Get the "execute-api" ARN. * * @default - The default behavior applies when no specific route, or stage is provided. * In this case, the ARN will cover all routes, and all stages of this API. * Specifically, if 'route' is not specified, it defaults to '*', representing all routes. * If 'stage' is not specified, it also defaults to '*', representing all stages. */ public arnForExecuteApiV2(route?: string, stage?: string): string { return Stack.of(this).formatArn({ service: 'execute-api', resource: this.apiId, arnFormat: ArnFormat.SLASH_RESOURCE_NAME, resourceName: `${stage ?? '*'}/${route ?? '*'}`, }); } ``` I removed "Method" and "Path" entirely since these are not even appropriate to use as terms for websockets. I used Route instead. ### Description of how you validated changes Updated Tests, there were 4 tests before: * get arnForExecuteApi * is now using route, and intentionally uses a route with no `$` to check that the `$` is being added correctly. * get arnForExecuteApi with default values * is now using route * get arnForExecuteApi with ANY method (removed) * doesn't make any sense here because "ANY" is not a term used with websockets, and method does not exist. Thus, removed this test * throws when call arnForExecuteApi method with specifing a string that does not start with / for the path argument. (removed) * This test is checking for a specific format for path, which is not needed since the route can be anything. Also path does not exist. This leaves 2 total tests now. Added a new integ function, `integ.api-grant-invoke.ts` and used --update-on-failed with my personal account to bootstrap new snapshots to match. For this test I included an iam role and 2 arns, one with default settings and one with `.arnForExecuteApi('connect', 'prod')` Intentionally left off the `$` to check that it's being added. All tests and integ are passing. ### Checklist - [x] My code adheres to the [CONTRIBUTING GUIDE](https://github.com/aws/aws-cdk/blob/main/CONTRIBUTING.md) and [DESIGN GUIDELINES](https://github.com/aws/aws-cdk/blob/main/docs/DESIGN_GUIDELINES.md) ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
|
Comments on closed issues and PRs are hard for our team to see. |
Describe the bug
In API gateway when building a websocket, the current function for arnForExecuteApi is too similar to the original function created for rest API.
The function would produce an arn like this (with default / no args)
"Resource": "arn:aws:execute-api:us-east-1:acc:apiId/*/*/*",which is an issue because there are too many asterisks. When using an IAM authorizer on the websocket API, having too many wildcards like this causes the IAM Authorizer to deny the iam role from calling the API. You need to have the exact number of wild cards.
Websocket ARNs are structured differently than REST APIs
They look like this:
arn:aws:execute-api:us-east-1:acc:apiId/stage/$connectThis means to get all stages and all routes, you need an arn like this :
"Resource": "arn:aws:execute-api:us-east-1:acc:apiId/*/*",in IAM.
The only way around this would be if users were trimming off the last 2 characters, but ideally the CDK should produce this expected output instead with only 2
/*wildcards.Regression Issue
Last Known Working CDK Version
No response
Expected Behavior
Calling arnForExecuteApi for a websocket API should return an ARN in this structure
arn:aws:execute-api:us-east-1:acc:apiId/*/*Current Behavior
The function arnForExecuteApi produces
arn:aws:execute-api:us-east-1:acc:apiId/*/*/*Reproduction Steps
Create websocket API in CDK
call arnForExecuteApi to build arn
Possible Solution
arnForExecuteApi is currently written with 3 arguments as inputs, and the
/*values are filled in when using no arguments. The arguments are method, path and stage. But these arguments are keywords used in REST API and are not appropriate for Websockets which are fundamentally different. In a websocket API there are stages and Routes. So the function needs to be edited to only use these 2 args, in which case using it with no args will default to 2 x/*values tagged onto the arn.Additional Information/Context
No response
CDK CLI Version
Any / Latest
Framework Version
No response
Node.js Version
v18.18.0
OS
macOS Sequoia (15.2)
Language
TypeScript
Language Version
5.6.3
Other information
More in depth on the issue here #33100 (wrote the PR first)
The text was updated successfully, but these errors were encountered: