api gateway lambda permissions

[samallisonds]

I have been experiencing issues with the lambda execute permission not being in place when deploying a stack, or new function, for the first time. I've been resolving it manually within the API Gateway console.

I've finally had a closer look... the stack does create a permission, but it is with the suffix 'Stage'. In my case I am supplying a specific StageName to the AWS::Serverless::Api resource. Actually to be more accurate I have "StageName: !Ref Stage", where Stage is a parameter to the template. Judging by the line linked below this can't be resolved, and rather unhelpfully 'Stage' is used instead. Perhaps this should be 'AllStages'?

https://github.com/awslabs/serverless-application-model/blob/a3a6d5211ed06fd77bdeb649d7277d0cc7843f56/samtranslator/model/eventsources/push.py#L367

[brettstack]

@samallisonds thanks for bringing this to our attention. I think this should be stage_suffix = "*". Do you want to submit a PR? Or shall I?

[brettstack]

I was too quick to jump to this conclusion. I'll need to investigate further.

[samallisonds]

Great - thanks for looking!

[samallisonds]

I thought that I'd worked around this by removing my "!Ref Stage" instances and just hardcoding my stage name. However today I discovered this wasn't as successful as I'd thought.

After much playing around creating and destroying stacks the only thing I found that worked reliably was creating my own permission with a dependency on the stage

  FooFunctionPostResourcePermissionDoubleCheck:
    Type: AWS::Lambda::Permission
    Properties:
      FunctionName: !Ref FooFunction.Alias
      Action: lambda:InvokeFunction
      Principal: apigateway.amazonaws.com
      SourceArn: !Sub arn:aws:execute-api:${AWS::Region}:${AWS::AccountId}:${RestApi}/${RestApibarStage}/GET/foo*

I seemed to need to add the * on the end to make it a distinct permission from the one that SAM creates itself? Guessing there.... but it didn't work without it

The permission that SAM creates only has a dependency on the restapi, and it just hardcodes the value for the stage.

For reference in this stack I have two functions connected to an API with a swagger definition. I have various other resources. The permissions problem consistently effects the same function, while the other is always OK. In the CloudFormation events log the failing permission is created first.

[brettstack]

Glad you worked around it, but I'm not sure why the permission SAM generates for you didn't work. It's hard to root cause your actual problem without more info on the template.

[patrickgreenwell]

I ran into this issue today when I was working through things, it looks to be some issue with the AutoPublishAlias: aliasName I removed that from my SAM Template and the permissions came back on my Lambda.

Funny thing is though that when I Viewed the Overview of the stack in the lambda console when I had the AutoPublishAlias set that the permissions were there, but not included as sub-object of the lambda or the version.

Contrast this with after removing the Alias:

My Swagger file didn't contain the alias in it's x-amazon-apigateway-integration object

x-amazon-apigateway-integration:
        type: aws_proxy
        httpMethod: POST
        uri: 
          Fn::Sub: "arn:aws:apigateway:${AWS::Region}:lambda:path/2015-03-31/functions/${LambdaFunction.Arn}/invocations"

This might just be a further symptom of how the transform and permissions application gets executed, and various other things might cause the same issue.

I'll have to try adding the alias name to the integration in swagger and see if that fixes it, though I suspect since the alias is pointer to a version it might have the same issue.

[georgealton]

I've just had exactly the same experience as @patrickgreenwell

[keetonian]

@samallisonds Could you post an example template that reproduces this issue?

[samallisonds]

I'd love to - I started trying to produce a minimal cut down version, but it didn't cause the same effect. The real template is considered a little too sensitive to share publicly as is unfortunately. Are you an AWS employee, and is there a private way I could share?

[keetonian]

Yes. Feel free to send me an email.

[samallisonds]

Great - it is on the way @keetonian

[keetonian]

End result: an API path was requiring an extra parameter on the end (example: /path/foo) and the associated Function API Event path was expecting only /path. Issue was fixed by updating the Function API Event path to be /path/* or /path*.