Execution failed due to configuration error: Invalid permissions on Lambda function

Question

I am building a serverless application using AWS Lambda and API Gateway via Visual Studio. I am working in C#, and using the serverless application model (SAM) in order to deploy my API. I build the code in Visual Studio, then deploy via publish to Lambda. This is working, except every time I do a new build, and try to execute an API call, I get this error:

Execution failed due to configuration error: Invalid permissions on Lambda function

Doing some research, I found this fix mentioned elsewhere (to be done via the AWS Console):

Fix: went to API Gateway > API name > Resources > Resource name > Method > Integration Request > Lambda Function and reselected my existing function, before "saving" it with the little checkmark.

Now this works for me, but it breaks the automation of using the serverless.template (JSON) to build out my API. Does anyone know how to fix this within the serverless.template file? So that I don't need to take action in the console to resolve? Here's a sample of one of my methods from the serverless.template file

{
  "AWSTemplateFormatVersion" : "2010-09-09",
  "Transform" : "AWS::Serverless-2016-10-31",
  "Description" : "An AWS Serverless Application.",

  "Resources" : {

    "Get" : {
      "Type" : "AWS::Serverless::Function",
      "Properties": {
        "VpcConfig":{
          "SecurityGroupIds" : ["sg-111a1476"],
          "SubnetIds" : [ "subnet-3029a769","subnet-5ec0b928"]
        },
        "Handler": "AWSServerlessInSiteDataGw::AWSServerlessInSiteDataGw.Functions::Get",
        "Runtime": "dotnetcore2.0",
        "CodeUri": "",
        "MemorySize": 256,
        "Timeout": 30,
        "Role": null,
        "Policies": [ "AWSLambdaBasicExecutionRole","AWSLambdaVPCAccessExecutionRole","AmazonSSMFullAccess"],
        "Events": {
          "PutResource": {
            "Type": "Api",
            "Properties": {
              "Path": "/",
              "Method": "GET"
            }
          }
        }
      }
    },

Timberland

Thank you SO MUCH for this tip. I had no idea the AWS console seems to have this bug. I was able to fix it following your advice but also fixed my terraform code to add this in as well. – Triangulation

Thank you sooo much for this post. I had a similar problem and was able to resolve it with the information provided in this post! – Triangulation

Awesome :) Glad it helped. – Timberland

fwiw, I had this error because I had the incorrect path set in the "AWS::Serverless::Function > Properties > Events > Event > path" of the sam template – Guenon

Answer 1

You may have an issue in permission config, that's why API couldn't call your lambda. try to explicitly add to template.yaml file invoke permission to your lambda from apigateway as a principal here's a sample below:

  ConfigLambdaPermission:
    Type: "AWS::Lambda::Permission"
    DependsOn:
    - MyApiName
    - MyLambdaFunctionName
    Properties:
      Action: lambda:InvokeFunction
      FunctionName: !Ref MyLambdaFunctionName
      Principal: apigateway.amazonaws.com

Here's the issue that was reported in SAM github repo for complete reference and here is an example of hello SAM project

If you would like to add permission by AWS CLI for testing things out, you may want to use aws lambda add-permission. please visit official documentation website for more details.

Cyril

I was specifying the property SourceArn, which I was defining incorrectly. Based on your answer, I checked the documentation and I decided to remove that property and then it started to work without any problems. I was using: SourceArn: !Sub arn:aws:execute-api:${AWS::Region}:${AWS::AccountId}:${ApiGateway}/*/POST/*" No idea what was the problem. – Cardiac

Checking the permissions on another lambda function that I linked to an API Gateway using the console: (If you go to your lambda and then got to Configuration->Permissions->Policy Statements) I saw that the format of the SourceARN is quite different: arn:aws:execute-api:$AWS_REGION:$AWS_ACCOUNT:$API_ID/authorizers/$SOME_ID the last part (SOME_ID) I don't know where that comes from or what it means, but clearly the format I was using is totally different, perhaps that was the reason of the Invalid permissions on Lambda function error. – Cardiac

Answer 2

I had a similar issue - I deleted then re-installed a lambda function. My API Gateway was still pointing at the old one, so I had to go into the API Gateway and change my Resource Methods to alter the Integration Request setting to point to the new one (it may look like it's pointing to the correct one but wasn't in my case)

Semitic

I had the same case. Thank you for this note! – Outstay

Unfortunately that is not a valid solution as this represent an underlying bug with AWS. Also if you have a Cloudformation template you cannot modify resources into the console. – Espy

Please note that this solution works for me. Even if the integration APPEARS to point to the correct lambda, you have to re-select it to get it to work. HOWEVER this specific solution does not work on the new AWS API Gateway console. I had to go back to the old API console. – Enfleurage

Answer 3

I was having the same issue but I was deploying through Terraform. After a suggestion from another user, I reselected my Lambda function in the Integration part of the API Gateway, and then checked what changed in my Lambda permissions. Turns out I needed to add a "*" where I was putting the stage name in the source_arn section of the API Gateway trigger in my Lambda resource. Not sure how SAM compares to Terraform but perhaps you can change the stage name or just try this troubleshooting technique that I tried.

My SO posting: AWS API Gateway and Lambda function deployed through terraform -- Execution failed due to configuration error: Invalid permissions on Lambda function

Trimerous

I had a similar terraform deployment error to and was able to fix it by adding in the additional permission in my terraform code. I found I had to go into the lambda function and look at the effective policy to see the difference. I discovered that with the policy has the "statement ID" it's one that was done via terraform, and when it has a GUID looking ID it's one done via the console. This helped me figure out the correct one to add. – Triangulation

It would seem this is a bug based on this post: github.com/terraform-providers/terraform-provider-aws/issues/… – Triangulation

Thank you sooo much for this post. I had a similar problem and was able to resolve it with the information provided in this post! – Triangulation

Answer 4

Same error, and the solution was simple: clearing and applying the "Lambda Function" mapping again in the integration setting of the API Gateway.

My mapping looks like this: MyFunction-894AR653OJX:test where "test" is the alias to point to the right version of my lambda

The problem was caused by removing the ALIAS "test" on the lambda, and recreating it on another version (after publishing). It seems that the API gateway internally still links to the `old' ALIAS instance. You would expect that the match is purely done on name...

Bonus: so, via the AWS console you cannot move that ALIAS, but you can do this via the AWS CLI, using the following command:

aws lambda --profile <YOUR_PROFILE> update-alias --function-name <FUNCTION_NAME> --name <ALIAS_NAME> --function-version <VERSION_NUMBER>

Thickskinned

Answer 5

I had the same issue. I changed the integration to mock first, i.e unsetting the integration type to Lambda, and then after one deployment, set the integration type to lambda again. It worked flawlessly thereafter.

I hope it helps.

Nomenclator

Answer 6

Facing the same issue, I figured out the problem is : API Gateway is not able to invoke the Lambda function as I couldn't see any CloudWatch logs for the lambda Function.

So firstly I went through API Gateway console and under the Integration Request - gave the full ARN for the Lambda Function. and it is started working.

Secondly, through the CloudFormation

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

Lancaster

I was missing credentials and your answer helped me see that. Cheers! – Wearing

Answer 7

The documentation for AWS lambda resource permissions shows 3 levels of access you can filter or wildcard, /*/*/*, which is documented as $stage/$method/$path. However, their example and most examples online only use 2 levels and I was bashing my head against the wall using 3 only to get Access Denied. I changed down to 2 levels and lambda then created the trigger. Hopefully, this will save someone from throwing their computer against the wall.

Yand

This saved me hours, it looks like it's two levels like you say: arn:partition:execute-api:region:account-id:api-id/stage/route-key docs.aws.amazon.com/apigateway/latest/developerguide/… – Triforium

Answer 8

I had the same problem so I deleted then created the stack and it worked.

Jud

Answer 9

Looks like "Execution failed due to configuration error: Invalid permissions on Lambda function" is a catch all for multiple things :D

I deployed a stack with CloudFormation templates and hit this issue.

I was using the stage name in the SourceArn for the AWS::Lambda::Permission segment.

when i changed that to a * AWS was a bit more explicit about the cause, which in my case happened to be an invalid Handler reference (I was using Java, the handler had moved package) in the AWS::Lambda::Function section.

Also, when i hit my API GW i got this message

{
    "message": "Internal server error"
}

It was only when I was at the console and sent through the payload as a test for the resource that I got the permissions error.

If I check the Cloudwatch logs for the API GW when I configured that, it does indeed mention the true cause even when the Stage Name is explicit.

Lambda execution failed with status 200 due to customer function error: No public method named ...

Messalina

Answer 10

In my case, I got the error because the Lambda function had been renamed. Double-check your configuration just in case.

Technically, the error message was correct—there was no function, and therefore no permissions. A helpful message would, of course, have been useful.

Mors

Answer 11

Adding to the pile, I was seeing this error message in the 'full' cloudwatch logs for the API, but it wasn't until I ran a test in the web ui that I got the far more informative :

Execution failed due to configuration error: API Gateway does not have permission to assume the provided role arn:aws:iam::***:role/LambdaExecutionRole-***-***-***

API Gateway -> Resources -> (Select endpoint) -> Test Tab

Reptilian

I fixed this issue via adding API Gateway to the list of entities allowed to assume that role, and started getting the Execution failed due to configuration error: Invalid permissions on Lambda function error again, so this might be a circle jerk. – Reptilian

Answer 12

In my case, I had an invalid path for my rest endpoint, pointing to something that I didn't have. Fixing the path, to point to the correct path, fixed my problem. Example of my correct path in the SAM framework:

ExampleEndpoint:
    Type: AWS::Serverless::Function
    Properties:
      FunctionName: !Sub ${StageName}-${ProjectName}-example
      CodeUri: src/lambdas
      Handler: example.handler
      Events:
        ExampleEventApi:
          Type: Api
          Properties:
            RestApiId:
              Ref: ExampleApi
            Path: /something/{value1}/{value2}
            Method: put

Path: /something/{value1}/{value2}

Rutty

Answer 13

I had a similar problem and was using Terraform. It needed the policy with the "POST" in it. For some reason the /*/ (wildcard) policy didn't work?

Here's the policy and the example terraform I used to solve the issue.

Many thanks to all above.

Here is what my Lambda function policy JSON looked like and the terraform:

    {
      "Version": "2012-10-17",
      "Id": "default",
      "Statement": [
        {
          "Sid": "AllowAPIGatewayInvoke",
          "Effect": "Allow",
          "Principal": {
            "Service": "apigateway.amazonaws.com"
          },
          "Action": "lambda:InvokeFunction",
          "Resource": "arn:aws:lambda:us-east-1:999999999999:function:MY-APP",
          "Condition": {
            "ArnLike": {
              "AWS:SourceArn": "arn:aws:execute-api:us-east-1:999999999999:d85kyq3jx3/test/*/MY-APP"
            }
          }
        },
        {
          "Sid": "e841fc76-c755-43b5-bd2c-53edf052cb3e",
          "Effect": "Allow",
          "Principal": {
            "Service": "apigateway.amazonaws.com"
          },
          "Action": "lambda:InvokeFunction",
          "Resource": "arn:aws:lambda:us-east-1:999999999999:function:MY-APP",
          "Condition": {
            "ArnLike": {
              "AWS:SourceArn": "arn:aws:execute-api:us-east-1:999999999999:d85kyq3jx3/*/POST/MY-APP"
            }
          }
        }
      ]
    }

    add in a terraform like this:


    //************************************************
    // allows you to read in the ARN and parse out needed info, like region, and account
    //************************************************
    data "aws_arn" "api_gw_deployment_arn" {
        arn = aws_api_gateway_deployment.MY-APP_deployment.execution_arn 
    }

    //************************************************
    // Add in this to support API GW testing in AWS Console.
    //************************************************
    resource "aws_lambda_permission" "apigw-post" {
        statement_id  = "AllowAPIGatewayInvokePOST"
        action        = "lambda:InvokeFunction"
        //function_name = aws_lambda_function.lambda-MY-APP.arn
        function_name = module.lambda.function_name
        principal     = "apigateway.amazonaws.com"

        // "arn:aws:execute-api:us-east-1:473097069755:708lig5xuc/dev/POST1/cloudability-church-ws"
        source_arn = "arn:aws:execute-api:${data.aws_arn.api_gw_deployment_arn.region}:${data.aws_arn.api_gw_deployment_arn.account}:${aws_api_gateway_deployment.MY-APP_deployment.rest_api_id}/*/POST/${var.api_gateway_root_path}"
    }

Triangulation

It would seem this is a bug based on this post: github.com/terraform-providers/terraform-provider-aws/issues/… – Triangulation

Answer 14

In my case I used Lambda path, that doesn't starts with a '/', like Path: "example/path" in my template.yaml. As a result AWS generate incorrect permission for this lambda:

{
 "ArnLike": {
  "AWS:SourceArn": "arn:aws:execute-api:{Region}:{AccountId}:{ApiId}/*/GETexample/path/*"
 }
}

So I fixed it by adding '/' to my lambda path in the template.

Botello

Answer 15

I had the same problem. For those using CDK, I simply deleted the API Gateway parts of the stack (or the entire stack if you have it separate), deployed it for them to actually get deleted, and then added them back in and deployed it again. That fixed the issue without me making any changes.

Rebound

Answer 16

I my case it was because my ApiGateway did not have the lambda:InvokeFunction permission attached to it

Piccard

As it’s currently written, your answer is unclear. Please edit to add additional details that will help others understand how this addresses the question asked. You can find more information on how to write good answers in the help center. – Juvenile

Answer 17

In my case, it was missing Resource-based policy on Lambda function side. My API Gateway returned 500 Internal Server Error and had printed the above Execution failed due to configuration error: Invalid permissions on Lambda function error on API GateWay log.

I found the root cause by navigating to my Lambda Function > Configuration > Permissions > Resource-based policy statements tab on AWS console.

However, I already had defined this policy in my CloudFormation template and this seemed to be a random error (all my other Lambda functions with the same configurations were working fine).

    MySampleLambdaPermission:
        Type: AWS::Lambda::Permission
        Properties:
            Action: lambda:InvokeFunction
            FunctionName: !Ref MySampleLambdaFunctionArn
            Principal: apigateway.amazonaws.com

I tried adding this using the AWS CLI and it worked for me.

    aws lambda add-permission \
    --function-name arn:aws:lambda:us-east-2:xxxxxxxx:function:xxx-xxx-MySampleLambdaFunction \
    --statement-id MySampleLambdaPermission \
    --action lambda:InvokeFunction \
    --principal apigateway.amazonaws.com

Wintery