How to add lambda invoke role in custom authorizer of api gateway using serverless framework - aws-api-gateway

I would like to add Lambda invoke role in custom authorizer for an api gateway using serverless framework.
events:
- http:
path: controls
method: GET
cors: ${self:custom.lambdaCORS}
authorizer:
arn: arn:aws:lambda:us-east-1:XYZ:function:SLS-XYZ
managedExternally: true
identitySource: method.request.header.x-api-key
resultTtlInSeconds: 0
type: request
Can someone help me in finding the property under authorizer to add "Lambda invoke role". I was able to do it manually from aws console. I am trying to access authorizer defined in other region. It seems API gateway needs a permission to invoke lambda authorizer in another region.

So the solution I was able to come up with was to add a specific permission to the generate API Gateway Cloudformation template.
The AWS docs outline what the Cloudformation template should look like to add a permission for API Gateway to access a lambda:
https://aws.amazon.com/premiumsupport/knowledge-center/api-gateway-rest-api-lambda-integrations/#To_add_Lambda_invoke_permission_to_a_REST_API_with_a_Lambda_integration_using_a_CloudFormation_template
So if you adapt that and add this block to the bottom of your serverless.yaml you should be able to access the Authorizer referenced by the FunctionName field!
resources:
Resources:
InvokeAuthorizerPermission:
Type: AWS::Lambda::Permission
Properties:
Action: "lambda:InvokeFunction"
FunctionName: ARN_OF_AUTHORIZER
Principal: "apigateway.amazonaws.com"
SourceArn: "arn:aws:execute-api:${aws:region}:${aws:accountId}:*/*/*/*"
Hope this helps another lost soul and I smashed my head up against this for a good long while!

Related

serverless framework: configuring a pre-existing lambda authenticator for HTTP API Gateway routes in serverless.yml

I would like to add a preexisting lambda authenticator to the routes of a preexisting http api gateway using the serverless framework. I have followed the docs, whereby I have specified the authorizer details under provider.httpApi (lines 15 to 18), and I have referenced the authorizer on the route(s) below (line 27 & 28). Though I get the error message:
Cannot setup authorizers for externally configured HTTP API
What am I doing wrong here? It must be for a HTTP API gateway and not a REST API gateway as thats what the current infra is configured as. Thanks
It looks like you're using an externally configured HTTP API (I'm guessing from the id being set). In such a situation, you cannot configure authorizers in this manner, you can only do so when you're provisioning HTTP API as a part of your serverless service. What you can do there, is to setup a shared authorizer in a more manual way as described in docs here: https://www.serverless.com/framework/docs/providers/aws/events/http-api#shared-authorizer
I came across this post when researching how to use API gateway authorizers and serverless framework. I was terraforming the API gateway therefore needed to terraform the authorizer as well. When created, I stashed the authorizer ID in a parameter store entry. This is a 6 character alphanumeric value such as tw9qgj. I then referenced the parameter as follows:
custom:
authorizerId: ${ssm:api_gateway_authoriser}
Then added the following block to each API e.g.
- httpApi:
path: /protected
method: get
authorizer:
id: ${self:custom.authorizerId}

how to restrict access to serverless api via resource policy?

a serverless api gateway stack built via cloudformation template ( see below) . I added a resource policy to whitelist a particular IP address. Does this block all other IP address, without specifying a black list or do I have add a IpRangeBlacklist values as well?
Resources:
serverlessapiGateway:
Type: AWS::Serverless::Api
Properties:
Auth:
ResourcePolicy:
IpRangeWhitelist:
- "10.20.30.40"
Verified, only list of IP under IpRangeWhitelist range are allowed. I wonder if there is a way to customize the error message we get, when not allowed.

Enable CloudWatch logs in API GatewayV2 Stage with cloud formation

There is a similar question but it does not use AWS::ApiGatewayV2::Stage, and I need the AutoDeploy that only the V2 seems to provide.
How do I enable CloudWatch logs and log full message data (as per the image) using CloudFormation in an AWS API Gateway?
I can't find anything at the documentation for the Stage
https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-apigatewayv2-stage.html#cfn-apigatewayv2-stage-deploymentid
I am using an autodeployed stage. I am able to create the log groups, the IAM role to write logs in CloudWatch, but I can't enable the logging itself.
wsApiGateway:
Type: AWS::ApiGatewayV2::Api
Properties:
Name: foo-ws-gateway
Description: Api Gateway for Websockets
ProtocolType: WEBSOCKET
RouteSelectionExpression: $request.body.action
DisableExecuteApiEndpoint: true # I use custom domain
# routes and integrations ommitted.
wsApiStage:
Type: AWS::ApiGatewayV2::Stage
DependsOn:
- wsConnectRoute
- wsSendRoute
- wsDisconnectRoute
Properties:
StageName: production
Description: Autodeploy in production
AutoDeploy: true
ApiId: !Ref wsApiGateway
AccessLogSettings:
DestinationArn: !GetAtt wsApiGatewayLogGroup.Arn
Format: '{"requestTime":"$context.requestTime","requestId":"$context.requestId","httpMethod":"$context.httpMethod","path":"$context.path","routeKey":"$context.routeKey","status":$context.status,"responseLatency":$context.responseLatency, "responseLength":$context.responseLength, "integrationError":$context.integration.error}'
I also had to go to ApiGateway previous version to define the Account so that I could specify the IAM role ARN that has write access to CloudWatch logs in the account (The section on Settings at,the console's API Gateway). It doesn't seem to have a AWS::ApiGateway2::Account.
apiGatewayAccountConfig:
Type: "AWS::ApiGateway::Account"
Properties:
CloudWatchRoleArn: !GetAtt apiGatewayWatchLogsRole.Arn
How do I enable CloudWatch logs and log full message data (as per the image) using CloudFormation in an AWS API Gateway?
You can't. Execution logs are not supported by HTTP API (i.e. ApiGatewayV2) as explained by AWS here:
HTTP APIs currently support access logging only, and logging setup is different for these APIs. For more information, see Configuring logging for an HTTP API.

Public path for API Gateway configured to use Cognito Authorizer

I have a Lambda being exposed to the world through API Gateway. The default authorizer is configured as a Cognito user pool and everything works fine.
I need to be able to expose just one of the endpoints without requiring the client to provide an authorization.
I'm using AWS SAM for defining the API and I couldn't find a way to specify an exception for the default authorizer.
How could this be done?
As it turns out it is in fact possible to disable the authorizer for one of the endpoints.
Simply set:
Properties:
Auth:
Authorizer: NONE
More information here: https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-property-api-apiauth.html

How to get the auto generated RestApi from my AWS SAM template? To use in another SAM template

I used AWS SAM to generate my Lambda/APIs. But I want to be able to get this RestApi so I can use it in another SAM template.
The idea is to have 1 base infra CloudFormation/SAM template that creates the network, ALB, API Gateway things
Then each "micro-service" will have its own SAM template and it will create API endpoints referencing this "root" RestApi by specifying the RestApiId attribute
Is this a correct approach? Wonder if when I deploy each service, will it remove the APIs for the other services?
You can access default auto generated RestApi as ServerlessRestApi. This is logical resource id for auto generated RestApi resource.
ServerlessRestApi access example in template.yaml is as follows.
Outputs:
ApiRootURL:
Description: API Root URL
Value: !Sub "https://${ServerlessRestApi}.execute-api.${AWS::Region}.amazonaws.com/${ServerlessRestApi.Stage}"
You can see ServerlessRestApi in the resource list of you CloudFormation stack. ServerlessRestApi is not documented, so it might be changed in the future version.