-
Notifications
You must be signed in to change notification settings - Fork 5.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: support externally-managed custom authorizers #7327
feat: support externally-managed custom authorizers #7327
Conversation
There are use cases where an API creator does not have permissions to add permissions to the custom authorizer lambda; one example is when the custom authorizer lambda exists in a separate AWS account. In these cases, we need to be able to omit the `AWS::Lambda::Permission` resource from the stack. This change adds the `managedExternally` attribute to the `authorizer`. When `managedExternally` is `true`, the stack will not create the `AWS::Lambda::Permission` resource. **Important note:** The permission does still need to be created before the stack is deployed, or creating the authorizer will fail.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks great @glb Thank you!
Codecov Report
@@ Coverage Diff @@
## master #7327 +/- ##
==========================================
+ Coverage 87.89% 87.89% +<.01%
==========================================
Files 240 240
Lines 8861 8863 +2
==========================================
+ Hits 7788 7790 +2
Misses 1073 1073
Continue to review full report at Codecov.
|
Thanks @medikoo ! Any idea when a release might happen? I'd like to pick up this and another fix that's gone in since v1.63.0. |
Hopfully tomorrow |
Yay! Thank you! |
There are use cases where an API creator does not have permissions to add permissions to the custom authorizer lambda; one example is when the custom authorizer lambda exists in a separate AWS account. In these cases, we need to be able to omit the `AWS::Lambda::Permission` resource from the stack. This change adds the `managedExternally` attribute to the `authorizer`. When `managedExternally` is `true`, the stack will not create the `AWS::Lambda::Permission` resource. **Important note:** The permission does still need to be created before the stack is deployed, or creating the authorizer will fail.
What did you implement
There are use cases where an API creator does not have access to add permissions to the custom authorizer function; one example is when the custom authorizer function exists in a separate AWS account. In these cases, we need to be able to omit the
AWS::Lambda::Permission
resource that allows API Gateway to call the authorizer function from the stack.This change adds the
managedExternally
attribute to theauthorizer
. WhenmanagedExternally
istrue
, the stack will not create theAWS::Lambda::Permission
resource that allows API Gateway to call the authorizer function.Important note: The permission does still need to be created before the stack is deployed, or creating the authorizer will fail.
Closes #7296.
How can we verify it
serverless.yml (before)
toserverless.yml
.serverless package
..serverless/cloudformation-template-update-stack.json
to filea
.serverless.yml (managedExternally: true)
toserverless.yml
. The only difference is the addition of the linemanagedExternally: true
in the authorizer config.serverless package
..serverless/cloudformation-template-update-stack.json
to fileb
.a
andb
: the only differences should be:serverless package
)S3Key
for the code will be different (it is updated for each run ofserverless package
)AWS::Lambda::Permission
namedAuthorizerLambdaPermissionApiGateway
for running the authorizer will not be present in fileb
serverless.yml (before)
serverless.yml (managedExternally: true)
There are also new and updated tests that verify the functionality.
Todos
Useful Scripts
npm run test:ci
--> Run all validation checks on proposed changesnpm run lint:updated
--> Lint all the updated filesnpm run lint:fix
--> Automatically fix lint problems (if possible)npm run prettier-check:updated
--> Check if updated files adhere to Prettier confignpm run prettify:updated
--> Prettify all the updated filesIs this ready for review?: YES
Is it a breaking change?: NO
cc @medikoo