Skip to content
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

Merged

Conversation

glb
Copy link
Contributor

@glb glb commented Feb 12, 2020

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 the authorizer. When managedExternally is true, the stack will not create the AWS::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

  1. Copy serverless.yml (before) to serverless.yml.
  2. Run serverless package.
  3. Copy .serverless/cloudformation-template-update-stack.json to file a.
  4. Copy serverless.yml (managedExternally: true) to serverless.yml. The only difference is the addition of the line managedExternally: true in the authorizer config.
  5. Run serverless package.
  6. Copy .serverless/cloudformation-template-update-stack.json to file b.
  7. Compare a and b: the only differences should be:
    • the API Gateway Deployment ID will be different (it is updated for each run of serverless package)
    • the S3Key for the code will be different (it is updated for each run of serverless package)
    • the AWS::Lambda::Permission named AuthorizerLambdaPermissionApiGateway for running the authorizer will not be present in file b
serverless.yml (before)
service: sample-service

provider:
  name: aws
  runtime: go1.x
  stage: ${opt:stage, 'dev'}

package:
  exclude:
    - ./**
  include:
    - ./bin/**

functions:
  sample:
    handler: bin/sample
    events:
      - http:
          path: /
          method: get
          authorizer:
            name: authorizer
            arn: arn:aws:lambda:us-east-1:111111111111:function:sample-authorizer-dev
            # authorizer result will be cached for this long
            resultTtlInSeconds: 0
            type: request
serverless.yml (managedExternally: true)
service: sample-service

provider:
  name: aws
  runtime: go1.x
  stage: ${opt:stage, 'dev'}

package:
  exclude:
    - ./**
  include:
    - ./bin/**

functions:
  sample:
    handler: bin/sample
    events:
      - http:
          path: /
          method: get
          authorizer:
            name: authorizer
            managedExternally: true
            arn: arn:aws:lambda:us-east-1:111111111111:function:sample-authorizer-dev
            # authorizer result will be cached for this long
            resultTtlInSeconds: 0
            type: request

There are also new and updated tests that verify the functionality.

Todos

Useful Scripts
  • npm run test:ci --> Run all validation checks on proposed changes
  • npm run lint:updated --> Lint all the updated files
  • npm run lint:fix --> Automatically fix lint problems (if possible)
  • npm run prettier-check:updated --> Check if updated files adhere to Prettier config
  • npm run prettify:updated --> Prettify all the updated files
  • Write and run all tests
  • Write documentation
  • Enable "Allow edits from maintainers" for this PR
  • Update the messages below

Is this ready for review?: YES
Is it a breaking change?: NO

cc @medikoo

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.
@glb glb requested a review from medikoo February 12, 2020 16:48
Copy link
Contributor

@medikoo medikoo left a 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-io
Copy link

Codecov Report

Merging #7327 into master will increase coverage by <.01%.
The diff coverage is 100%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master    #7327      +/-   ##
==========================================
+ Coverage   87.89%   87.89%   +<.01%     
==========================================
  Files         240      240              
  Lines        8861     8863       +2     
==========================================
+ Hits         7788     7790       +2     
  Misses       1073     1073
Impacted Files Coverage Δ
lib/plugins/aws/package/lib/mergeIamTemplates.js 100% <100%> (ø) ⬆️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 4493723...e8f8e90. Read the comment docs.

@medikoo medikoo merged commit 7abb23e into serverless:master Feb 12, 2020
@glb glb deleted the 7296-manage-authorizer-permissions-externally branch February 13, 2020 00:09
@glb
Copy link
Contributor Author

glb commented Feb 13, 2020

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.

@medikoo
Copy link
Contributor

medikoo commented Feb 13, 2020

Any idea when a release might happen?

Hopfully tomorrow

@glb
Copy link
Contributor Author

glb commented Feb 13, 2020

Yay! Thank you!

astuyve pushed a commit that referenced this pull request Apr 15, 2020
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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Allow omitting the AWS::Lambda::Permission for cross-account authorizers
3 participants