Serverless-application-model: Support API Gateway Logging Metrics, Usage Plans, EndpointConfiguration, and CORS

Created on 8 Jan 2018  Â·  92Comments  Â·  Source: aws/serverless-application-model

Parent Tracking Issue for Logging, Usage Plans, CORS etc on API resources (Implicit and Explicit). As part of this, we will move to a model where all API features will be supported in both Implicit & Explicit definitions consistently.

  • [x] Logging
  • [x] Usage Plans queued for v1.21.0
  • [x] Custom Authorizers (AWS::ApiGateway::Authorizer and AWS Cognito) (#49) (#512)
  • [x] AWS_IAM
  • [x] Custom Domains v1.20.0
  • [ ] ACM
  • [x] Base Path Mapping
  • [x] Regional Endpoints

For deeper details on the different issues, see the appropriate issue that is referenced below.

areevent-source areresources areserverless-api areserverless-function priorit1-critical stagin-progress typfeature

Most helpful comment

Regarding the cors:true issue: could you please prioritize? Many users would like to utilize SAM to build web apps -- it is a huge percentage of use cases, many serveless app in fact are NOT "mobile first". Without direct CORS support, it is difficult to use SAM for web apps. Using Swagger with SAM to get around this can be painful and buggy.

All 92 comments

Regarding the cors:true issue: could you please prioritize? Many users would like to utilize SAM to build web apps -- it is a huge percentage of use cases, many serveless app in fact are NOT "mobile first". Without direct CORS support, it is difficult to use SAM for web apps. Using Swagger with SAM to get around this can be painful and buggy.

@rabowskyb All of these (in the issue) are being prioritize with high priority in the team and are going to be the first set of things we will address this year. The team is actively talking about how to move forward and we are trying to do this as quickly as we can. We don't have timelines to share, as of now though. I hope to share more soon.

Does this also mean it will be more straightforward to declare a AWS::ApiGateway::Authorizer resource with Type: "Cognito_user_pool" within a SAM template? There are a few unanswered requests for advice about this topic in the aws-sam-local issue 137 (https://github.com/awslabs/aws-sam-local/issues/137)

Can you confirm if this issue covers the built in AWS_IAM authorizer? It's a bit unclear from reading it but was referred to in the closure of https://github.com/awslabs/serverless-application-model/issues/49

@samwan Yes, we will be supporting AWS::ApiGateway::Authorizer

@steveparker-kcom Yes, this will cover the AWS_IAM authorizer.

I updated the list above to call this explicitly out. (Feel free to update or add more details as well)

Great news, thank you. My question was generally about API Authorizers but specifically about the IAM use case asked by @steveparker-kcom. Just a suggestion... when you ship this, I think a lot of people will appreciate documentation or examples specifically about IAM gateway authorization. Thank you again!

When you do implement the IAM piece, will be simple to get access to the Cognito identity in the lambda functions?

I think it is so close to being a very easy way to setup a website, complete with auth backend, as far as I can tell CORS and Cognito integration are the last pieces of the puzzle. (I could well be missing something with the Cognito bit, only just started looking).

Is it really impossible to configure API endpoints to require X-API-Key using SAM? I read #211 and thought it would be possible, but I haven't figured out a way to do it.

(I have to say I'm deeply disappointed. First I had to convert my project to a complex Swagger format to enable CORS, and now it seems I'm at a dead-end because of lack of X-API-Key support. These are very basic things and have been supported by API Gateway for years. Why is SAM progressing so slowly?)

@kennu, as a workaround you can use AWS_SAM_LOCAL environment variable in your handlers to detect running in sam-local and inject your authorizer data in the event.

@kind3r I am not sure how that will help me in enabling X-API-Key authorization for the real API Gateway endpoints?

@kennu sorry, I misunderstood, I thought you were reffereing to setting up authorizers locally.

So if I understand correctly now, you are trying to set API Key requirements per path/method from the swagger definition, just like you would in the API Gateway console under Method Request. I see that there is a x-amazon-apigateway-api-key-source API-level property that specifies where to get the API Key from. Now, I did not find a way to define the requirement of the API Key in x-amazon-apigateway-integration, but I did experiment with setting this up with the console and then exporting the swagger definition from the stage. What API Gateway console does, is it add an extra securityDefinitions that requires the X-API-Key header to be present. I then applies it to the security of the method:

securityDefinitions:
  api_key:
    type: "apiKey"
    name: "x-api-key"
    in: "header"
...
paths:
  /somepath:
    put:
      responses: {}
      security:
      - api_key: []
      x-amazon-apigateway-integration:
        uri: "arn:aws:apigateway:..."
        passthroughBehavior: "when_no_match"
        httpMethod: "POST"
        type: "aws_proxy"

If you allready have a custom authorizer for the method, then you should probably use x-amazon-apigateway-api-key-source: "AUTHORIZER" and return the API Key in the UsageIdentifierKey authorizer response.

Hope this helps.

Sorry @kind3r but it does not help. I do not wish to use a custom authorizer. I am trying to enable API Gateway’s built-in support for protecting endpoints with API keys. Same thing that Serverless Framework enables using private: true.

@kennu this is exactly what my example above does :) if you ignore the last part about the custom authorizer.

@kind3r Ah I see! I tried it earlier, but apparently I made a mistake in the syntax and lost faith when it was quietly ignored. After fixing it, it worked, thank you!

So just to recap, I used this global definition:

    securityDefinitions:
      api_key:
        type: "apiKey"
        name: "x-api-key"
        in: "header"

and this under each API method:

          security:
            - api_key: []

And there was no need to delete/recreate the stack, just a normal deploy.

Much happier with SAM now, although I still wish this API Key support would be clearly documented somewhere.

@kennu Sorry for being late to the party here. I am glad you finally got ApiKey working!

We accept PRs :)

We are tracking updates needed to our documentation in #251 and some progress has been made on the docs branch (we will merge into mainline once we cover the major gaps). I will make a note to address that doc update there.

On a sidenote:
We are also working towards supporting this 'natively' in the SAM definition, which I think would make this much clearer on how to add ApiKeys, among other things. More to share on that topic soon.

any updates this issue? oops,
especially, logging metrics

+1 this capability will be very attractive to us

Moving the stage to reflect this is in-progress.

As far as an update, nothing has changed. The team is working through these and we hope to share more soon.

@kennu I am struggling to enable API key support in my serverless project. It seems like the "security" line, etc. are just ignored by Cloudformation. I guess I have not put this in the right place in my template, but loads of trial and error has gotten me nowhere. Any chance you could post a complete template, so I can see the exact context of the "securityDefinitions" and "security" elements? Thanks!

@nordholm sorry my template is really big and not suitable for public copy-paste.

I think the best help with this problem would be that SAM / CloudFormation would show proper error messages when trying to submit an invalid Swagger definition. The way it currently silently swallows errors is very counter-productive.

@kennu Ok. I just noticed that what you quoted earlier is from a swagger definition, and I am trying to do this in the cloudformation (serverless) template.
Does anyone know if it is possible to specify the api key requirement directly in the template? Basically, I am trying to figure out the syntax to put in here, equivalent to the swagger example:

AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2016-10-31
Description: ESB PackingList API
Resources:
  XyZFunction:
    Type: AWS::Serverless::Function
    Properties:
      FunctionName: somefunction
      Handler: lambda.handler
      Runtime: python3.6
      CodeUri: ...
      Events:
        MyEvent:
          Type: Api
          Properties:
            Path: /mypath
            Method: get
# lines starting here...
          security:
            api_key:
              type: "apiKey"
              name: "x-api-key"
              in: "header"

@nordholm I don't think that's possible in SAM, I think you have to convert your whole project to be based on a Swagger definition. I.e. you will need a AWS::Serverless::Api resource with the DefinitionBody and so on.

In my project I am using API Gateway and Lambda functions. I need to implement custom authorizer for my API. I actually found a blueprint of custom authorizer, which I am going to use.

The thing, I do not understand, is how we are supposed to put custom authorizer in SAM template for now, since it doesn't have such properties in its specification.

The absence of support of custom authorizers in sam local is not a very big problem, I suppose. It is fine, that when testing locally, API will work without authorization. But I want to have one template both for testing app locally and for deployment.

Since that, I have the following questions:

  1. Should I describe my API in usual cloudfront template style (define authorizer and all my API resources)? Can I use sam-style function descriptions then and just point my lambda functions' events to logical ids of previously described API resources? As far as I understand, mixing of usual cloudfront style and sam is fine, since sam definitions are transformed in usual cloudfront style. But will such template work with sam local?
  2. Or should I just forget about sam-model and write usual cloudfront template? Will such template work with sam local and expose local api at all?

So, are there any recipies, how to create apps with custom authorizer and sam local without waiting for this feature to be implemented in sam local?

@gnemtsov I also have a custom authorizer in use in my project. I am not sure what the best way to accomplish this is, but for now I define the authorizer function itself in the template (just like any of the other functions) and then manually hook it up in the Api Gateway console after deployment. In order to ensure that requests are not able to bypass the authorizer if I forget to hook it up, my functions check for the presence of a token from the authorizer at runtime. Not particularly elegent, I know ;-)
It works well, however, in that I do not need to re-do the custom authorizer configuration in Api Gateway when the stack is re-deployed. It seems like CloudFormation is happily unaware of it and just leaves it alone. In other words, so far this has been a one-off configuration task after the first deployment.

I hope the SAM transformation will support this cleanly in the future.

@nordholm and @gnemtsov, until SAM adds first-class support for API Gateway Authorizers, you will need to write an inline swagger definition with api gateway integrations.

  RestApi:
    Type: AWS::Serverless::Api
    Properties:
      StageName: !Ref Stage
      DefinitionBody:
        swagger: "2.0"
        info:
          title: !Ref AWS::StackName
        ...
        paths:
          "/pets":
            get:
              x-amazon-apigateway-integration:
                httpMethod: POST
                type: aws_proxy
                uri: !Sub arn:aws:apigateway:${AWS::Region}:lambda:path/2015-03-31/functions/${ListPetsFunction.Arn}/invocations
                responses: {}
              security:
                - authorizer: []
        ...
        securityDefinitions:
          authorizer:
            type: apiKey
            name: Authorization
            in: header
            x-amazon-apigateway-authtype: custom
            x-amazon-apigateway-authorizer:
              authorizerUri: !Sub arn:aws:apigateway:${AWS::Region}:lambda:path/2015-03-31/functions/${Authorizer.Arn}/invocations
              authorizerResultTtlInSeconds: 300
              type: token

  ...

All of your functions will require a reference to the RestApi.

  ListPetsFunction:
    Type: AWS::Serverless::Function
    Properties:
      Handler: io.andrewohara.pets.ListPetsHandler
      CodeUri: ./pets-api/build/libs/pets-api.jar
      Policies:
        - DynamoDBReadPolicy:
            TableName: !Ref Pets
      Environment:
        Variables:
          PETS_TABLE_NAME: !Ref Pets
      Events:
        http:
          Type: Api
          Properties:
            Path: /pets
            Method: GET
            RestApiId: !Ref RestApi # add this ref to your api event

You also need to give Api Gateway permission to invoke your function.

  AuthorizerInvoationPolicy:
    Type: AWS::Lambda::Permission
    Properties:
      FunctionName: !Sub ${Authorizer.Arn}
      Action: lambda:InvokeFunction
      Principal: apigateway.amazonaws.com

I am EAGERLY awaiting first-class support for API Gateway Authorizers.

Hello, Is there any resolution to setting the API Gateway Cache TTL? Currently there is no way to address this issue and it is a huge pain for my department. I have not seen anything about this in awhile.

A lot of these features are now available - Cors, Regional Endpoints, Binary types, Logging, Metrics, CacheTTL. Checkout Release Notes

Custom Authorizers, Custom Domains and Usage Plans are not yet supported. So keeping the issue open for tracking.

@sanathkr, thanks for the update! I should be able to find a use for some of those. Hopefully the CORS flag will still be useful on top of the explicit swagger template I need for my custom authorizer.

We know AWS never provides estimated timelines for changes, but can you comment on whether custom authorizer support is at least already underway?

thanks all. I can finally give this repo a star!

I second @oharaandrew314 's question. It would be nice to know if the rest of the features (security specifically) are still in progress or have been stuck in the 'we'll come back to that' bucket.

@sanathkr "new features (CORS) are now available" 1.4.0 when they will be available in Cloud Formation? Immediately? or somehow I need to enable them in my template? Thx

@oharaandrew314

Thx for example, I tried stack below and no CORS specific items added to API Gateway:

AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2016-10-31
Resources:
  ServerlessRestApi:
    Type: 'AWS::Serverless::Api'
    Properties:
      StageName: Prod
      DefinitionBody:
        swagger: "2.0"
        securityDefinitions:
          sigv4:
            type: apiKey
            name: Authorization
            in: header
            x-amazon-apigateway-authtype: awsSigv4
        paths:
          # smt
      Cors:
        AllowHeaders: "'Content-Type,X-Amz-Date,Authorization,X-Api-Key,X-Amz-Security-Token'"
        AllowOrigin: "'*'"
        MaxAge: "'86400'"

@terma, I'm not sure where you got that cors code, but it's not what's in the example

@oharaandrew314 tried your example, still doesn't work. Should I enable Cors feature from SAM somehow in template?

@terma, to be honest, I still haven't switched over to the sam-provided CORS. I think you should create an issue for this.

@terma I have the same issue with the provided example (https://github.com/awslabs/serverless-application-model/blob/master/examples/2016-10-31/api_swagger_cors/template.yaml#L13).
The CORS headers are only set for the OPTIONS methods (preflight requests). All other methods have no CORS headers.

Is it possible to include accessLogSettings as configurable through AWS SAM? If we want to customize the format or destination ARN, we would need to configure this. Thanks for all your work on this project.

  • TTL cache per method
  • logging enablement
  • usage plans
  • cloudfront behaviour addition
  • API key setting
  • Parameterization limitation of 60 max
  • controlling swagger title others from paramaters

from SAM is keeping our progress blocked further...If any update on these lines would help...as I'm taking serverless on bigger scale delivery lines-the support on these would value add on serverless ecosystem.

Doing this outside additional steps thru aws cli - would be wacky in managing the deployments

Sorry long comment coming. Doing some catch up on this issue

@anandchristal Some of these are addressed. Please see the @sanathkr's comment above and where to find that information. Anything outside the first comment in this issue (made by me and has a list of features this issue is meant to address), please cut us a new issue and we can discuss there. (trying to keep this issue focused on its original intent).

@mouscous Please cut us a new issue and we can discuss there as it is outside the scope of this one.

@MMore see #346 for more details

@lstroud and @oharaandrew314 The rest of the things are still top priority for us to handle and get addressed.

I really hope IAM Authorization will come soon, it is the last part of the puzzle for me to finally drop building swagger templates now that CORS support is available.

Also, another popular AWS repo is AWS Amplify, and it using IAM authorization when calling an API, so I hope that that will make SAM prioritize getting IAM autorization in the future.

CORS support is great tho, keep up the good work!

@jfuss Unfortunately that's not the problem. I actually already use another logical id (#346). Any other hints?

@MMore So the options request is the only one that will automatically get the cors headers. For others, you have to manually pass from the Lambda response.

This is unfortunately the best we can do because APIGW does not support injecting headers into response for Lambda proxy type integration (which is the default for SAM). We tried many possible options to automatically inject this for you, but it turned out to be a limitation that we could not work around.

@sanathkr thanks, that's understandable. Then I propose adjusting the documentation to avoid further confusion.

Just wanted to give a quick update. There was a message about this issue on the #samdev Slack Channel yesterday. We are still working through this issue and it is not in the 'we will get to this later bucket'. We have Custom Authorizers scoped to work on in the coming weeks. For those in the Slack Channel, you should start seeing some chatter for us on this soon.

@MMore Would you be willing to send a PR with that information?

@bhallstein See #373.

In the future, please follow this guide.

Thank you — apologies, I missed that ticket.

Usage plans-any workaround at this time,I tried fusing with CF.when aws:serverless:api takes time to define stage,aws:apigateway:usageplan getting into some race state and failed as stage not found situation.

created stack just with api first and second run included usage plan(CF defintion) into sam...Anyone shot stuff could help

@bhallstein

You can use globals to add Cors to API's added to you functions

```yaml
Globals:
Api:
Cors:
AllowMethods: "'DELETE,GET,HEAD,OPTIONS,PATCH,POST,PUT'"
AllowHeaders: "'Content-Type, Authorization, X-Amz-Date, X-Api-Key, X-Amz-Security-Token'"
AllowOrigin: "'*'"
MaxAge: "'600'"
````

Is it currently possible to configure the integration response and method response of the method execution of an Api resource via SAM? I couldn't find a way to do it. If that is the case, will this issue also cover adding this capability?

@jfuss

I have created a SAM application in .net and I am having a similar request to https://github.com/awslabs/serverless-application-model/issues/165

Issues:

  1. Unable to deploy lambdas/api (as part of a stack) to a single non-prod stage
  2. Unable to specify stage deployments via implicit Event declarations

My infrastructure is as follows:

ExampleAPI =

  • 1 source code project with multiple handlers in the same project. (this currently has /getExamples for a list of all examples and then /getExample/{id} to get a specific example).
  • Each API resource points to a different lambda handler in Gateway config

Source Code=

  • Via serverless.template (in json) this outputs 2 lambdas (one for each handler, I like this).
  • The Api is implicitly defined via the Events section of the AWS::Serverless::Function

The response to the above ticket (closed) states it will be addressed in 248. Has this been addressed? Am i missing something? i am considering redesigning because at the moment the deploy (publish from visual studio AWS plugin) publishes the whole stack with "Prod" and "Stage" by default and deploys the api to both by default. I want to be able to deploy the stack to a dev stage (from the SAM code) and then ONLY be able to deploy the api to a PROD stage from the API Gateway dashboard when ready to move to production.

Let me know if I am missing something

@jfuss

Perhaps the highlighted area in the attached screenshot was where I thought something like StageName would be

sam template

@sanathkr How close are you guys to adding Custom Domain mapping? It would be nice to see this soon. Thanks and keep up the good work.

Hi,

I have a stack definition using sam with apis and lambdas wired together - pretty sweet so far (congrats) but some obvious things missing that will come in time no doubt.

Is there an example of incorporating API Keys and usage plans using vanilla cloud f resources, but within a sam context? My api is an 'implicit' one automagically generated so how do make such usage plan and key resources get a reference to an implicit api?

Thoughts / links to examples?

Cheers!

Am I mistaken or is the new cors option only available for explicit API Definitions using Swagger? (via API Documentation)

@sanathkr on https://github.com/awslabs/serverless-application-model/issues/248#issuecomment-379497015 you explained

So the options request is the only one that will automatically get the cors headers. For others, you have to manually pass from the Lambda response.

If I'm understanding correctly that means SAM + CORS is fundamentally incompatible with a custom authoriser for anything except CORS simple requests, due to api-gw limitations on the aws_proxy mechanics rather than anything SAM can fix, right?
Making the only option for APIs with more than just a GET method to push all the auth logic into the application code and abandon custom authorisers?

Any word on the AWS_IAM Authorizer?

Base Path Mapping have a checkbox, does that mean its done? In that case, which is the proper way of declaring it?

@Yottster You can access it with { "Ref": "INSERT_LOGICAL_API_ID.Stage" }

Hi, is it possible to enable the accessLogSettings already ? We need custom logging on our API Gateways and to have this set in an automated way that would be nice.

@mouscous and @jvanbrunschot-coolblue I had this same request and created #516 to request that feature

For those interested in Authorizers, the RFC for this feature is over here https://github.com/awslabs/serverless-application-model/issues/512 and will remain open until the end of this week. We'll begin implementation on this feature soon.

@evanpitt I've replied on #165

Seems like AccessLogsSettings can be enabled on the AWS::ApiGateway::Stage. https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-apigateway-stage-accesslogsetting.html.

When can we expect it in AWS::Serverless::Api.

@jvanbrunschot-coolblue I added an issue to implement support here: https://github.com/awslabs/serverless-application-model/issues/612. Go ahead and +1 the issue if you would like it prioritized.

Any update when AWS_IAM authorizer will be GA'ed?

Hello, I try to enable logging feature, but when I do :

      MethodSettings:
        - HttpMethod: "*"
          ResourcePath: "/*"
          LoggingLevel: INFO      # INFO or ERROR
          DataTraceEnabled: true  # Put logs into cloudwatch
          MetricsEnabled: true    # Enable detailed metrics (error 404, latence, ...)

I get CloudWatch Logs role ARN must be set in account settings to enable logging error when I deploy my stack with cloudformation. And I don't find any information on how to do the trick inside my cloudformation :thinking:

Edit: I find how to do:

  EmailApiRole:
    Type: AWS::IAM::Role
    Properties:
      AssumeRolePolicyDocument:
        Version: 2012-10-17
        Statement:
          - Effect: Allow
            Action: sts:AssumeRole
            Principal:
              Service: apigateway.amazonaws.com
      ManagedPolicyArns:
        - arn:aws:iam::aws:policy/service-role/AmazonApiGatewayPushToCloudWatchLogs

  # Allow api gateway to create cloudwatch logs
  EmailApiAccount:
    Type: AWS::ApiGateway::Account
    Properties: 
      CloudWatchRoleArn: !GetAtt EmailApiRole.Arn

https://docs.aws.amazon.com/apigateway/latest/developerguide/set-up-logging.html

Last section. This is a one-time setup per account.

On Fri, 16 Nov 2018 at 11:03 pm, Jacob Zak notifications@github.com wrote:

Hello, I try to enable logging feature, but when I do :

  MethodSettings:
    - HttpMethod: "*"
      ResourcePath: "/*"
      LoggingLevel: INFO      # INFO or ERROR
      DataTraceEnabled: true  # Put logs into cloudwatch
      MetricsEnabled: true    # Enable detailed metrics (error 404, latence, ...)

I get CloudWatch Logs role ARN must be set in account settings to enable
logging error when I deploy my stack with cloudformation. And I don't
find any information on how to do the trick inside my cloudformation 🤔

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/awslabs/serverless-application-model/issues/248#issuecomment-439373158,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAMlYEixiP00G63tII-joya9EoUybf5cks5uvql-gaJpZM4RW3tl
.

I was hoping to use SAM to build out my Identity Provider for AWS Transfer for SFTP and after a bunch of work it turns out SAM still doesn't support IAM Authorizers, which it seems like should have been one of the FIRST things it supported. Subscribing in hopes that I can actually use this tool in a year or so after my current project is done and dusted.

Between this, extra Stages that I can't get rid of, a mysterious 'Test' permission that allows any Stage to invoke my Lambda function, and getting told I shouldn't install Python modules into virtualenvs, I'm pretty underwhelmed.

Guess I should talk to my account rep about getting the priority on this feature bumped up.

@brandond you can use swagger to support IAM authorizers Here's how we have done it https://github.com/SumoLogic/sumologic-aws-lambda/blob/master/securityhub-forwarder/sam/template.yaml

Thanks @himanshu219, I might give that a try. I was hoping to avoid having to generate my own swagger; the whole point of using SAM was to build the API with only CloudFormation templates and Lambda function code. If I've got to provide a bunch of additional artifacts or configuration then I might as well just go back to using stock CloudFormation and not mess with changesets and such.

You may find AWS CDK gives the dream of ‘SAM Simplicity’ with enough functionality to actually be nice and useable.

Get Outlook for iOShttps://aka.ms/o0ukef


From: Brandon Davidson notifications@github.com
Sent: Saturday, January 19, 2019 6:08 pm
To: awslabs/serverless-application-model
Cc: 0xdevalias; Manual
Subject: Re: [awslabs/serverless-application-model] Support API Gateway Logging Metrics, Usage Plans, EndpointConfiguration, and CORS (#248)

Thanks @himanshu219https://github.com/himanshu219, I might give that a try. I was hoping to avoid having to generate my own swagger; the whole point of using SAM was to build the API with only CloudFormation templates and Lambda function code. If I've got to provide a bunch of additional artifacts or configuration then I might as well just go back to using stock CloudFormation and not mess with changesets and such.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHubhttps://github.com/awslabs/serverless-application-model/issues/248#issuecomment-455756129, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AAuA4ymq-GH56AGYGL8kFbS2AfXmrzdoks5vEsRvgaJpZM4RW3tl.

IAM RFC #781 for those interested

RFC for Custom Domain Names #783

API Gateway API Keys are not on that list? Would love to be able to create Lambda that requires API Key from SAM template.

These limitations of SAM templates have now been a high priority for over a year, any news on when they are likely to be addressed? Specifically I'm interested in API keys, CORS and enabling logging.

@Recodify Many of these have already been completed for some time now.

Logging in v1.4.0
CORS in v1.4.0

@jfuss Ah brilliant, many thanks for pointing that out.
What about requiring an API key, is that currently possible without using a swagger definition?

Would love API Keys. That was merged on #444 and never released.

Would love API Keys. That was merged on #444 and never released.

I'm also interested in seeing this be implemented. Any timelines on it? I also noticed it's not on the checklist at the top.

Thanks!

@deleugpn @jona Thanks for following up on this. #444 can't be merged into develop in its current form. It needs to be updated to fit within the Auth syntax we've added to AWS::Serverless::Api since it was merged. We have not currently prioritized this work internally so the fastest way to get it into SAM is for someone from the community to contribute the necessary changes.

547 is specifically tracking adding support for API Keys to AWS::Serverless::Api. It links to #827 as a good example PR to follow for anyone who wants to implement this feature.

Any updates on this? not being able to add metrics using MethodSettings makes it pretty hard to use serverless in a production environment.

@crawforde Please see above comment (it's have been released for some time now) https://github.com/awslabs/serverless-application-model/issues/248#issuecomment-463063879

Found the docs on it. Thanks! Seems like there was another issue that was preventing this from working.

@jfuss, any update on support for throttling?

Will (or does) it consider all throttling definitions (AWS::ApiGateway::UsagePlan Throtle; AWS::ApiGateway::UsagePlan ApiStages Throtle; AWS::Serverless::Api MethodSettings)?

I am trying to verify the response messages returned to see whether my response template works when throttling but no matter what all jobs are queued and throttling never occurs on SAM CLI. Maybe I have to do this on AWS. Any hints?

@liam-sage Are you trying to test throttling with 'start-api'? I don't think that really does anything other than add some routes and invoke your function through a simple Flask CGI wrapper - any of the more complicated stuff that API Gateway does like authorizers, throttling, etc are not included.

Hi, do we have the feature to enable logging for ApiGateway when deployed using SAM templet?

We have created an RFC #1141 to support creation of Api keys for Auth with Usage Plans. Please let us know your thoughts on the RFC

@phanikrishnahari

You can't have it directly on AWS::Serverless::Api as discussed, but AWS SAM supports anything AWS CloudFormation supports so why not to apply this into your code. Template example here.

Then you can just

MyApi:
  Type: AWS::Serverless::Api
  Properties:
    MethodSettings: # Use execution logging  
    AccessLogSetting: # Use access logging

@jfuss this was reviewed as part of backlog review. What's missing here that we need?

Was this page helpful?
0 / 5 - 0 ratings