Выполнение не выполнено из-за ошибки конфигурации: недопустимые разрешения для функции Lambda
Я создаю безсерверное приложение с использованием AWS Lambda и API Gateway через Visual Studio. Я работаю в C# и использую модель бессерверного приложения (SAM) для развертывания моего API. Я создаю код в Visual Studio, а затем развертываю с помощью публикации в Lambda. Это работает, за исключением того, что каждый раз, когда я делаю новую сборку и пытаюсь выполнить вызов API, я получаю эту ошибку:
Выполнение не выполнено из-за ошибки конфигурации: недопустимые разрешения для функции Lambda
Проведя некоторые исследования, я обнаружил, что это исправление упоминается в другом месте (должно быть сделано с помощью консоли AWS):
Исправлено: перешел к "Шлюз API"> "Имя API"> "Ресурсы"> "Имя ресурса"> "Метод"> "Запрос на интеграцию"> "Лямбда-функция" и повторно выбрал мою существующую функцию, прежде чем "сохранить" ее с помощью маленькой галочки.
Теперь это работает для меня, но это нарушает автоматизацию использования serverless.template (JSON) для построения моего API. Кто-нибудь знает, как это исправить в файле serverless.template? Так что мне не нужно предпринимать действия в консоли, чтобы решить? Вот пример одного из моих методов из файла serverless.template
{
"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"
}
}
}
}
},
13 ответов
У вас может быть проблема в конфигурации разрешений, поэтому API не может вызвать вашу лямбду. попробуйте явно добавить в файл template.yamlinvoke разрешение на вашу лямбду от apigateway как principal вот образец ниже:
ConfigLambdaPermission:
Type: "AWS::Lambda::Permission"
DependsOn:
- MyApiName
- MyLambdaFunctionName
Properties:
Action: lambda:InvokeFunction
FunctionName: !Ref MyLambdaFunctionName
Principal: apigateway.amazonaws.com
Вот проблема, о которой сообщалось в репозитории SAM на github для полной справки, и вот пример проекта hello SAM
Если вы хотите добавить разрешение AWS CLI для тестирования, вы можете использовать aws lambda add-permission. пожалуйста, посетите официальный сайт документации для получения более подробной информации.
У меня была аналогичная проблема - я удалил, а затем переустановил лямбда-функцию. Мой API-шлюз все еще указывал на старый, поэтому мне пришлось зайти в API-шлюз и изменить свои методы ресурсов, чтобы изменить параметр Integration Request, чтобы он указывал на новый (может показаться, что он указывает на правильный, но не не в моем случае)
У меня была та же проблема, но я развертывал через Terraform. После предложения от другого пользователя я повторно выбрал свою функцию Lambda в части интеграции шлюза API, а затем проверил, что изменилось в моих разрешениях Lambda. Оказывается, мне нужно было добавить "*", где я помещал имя этапа в раздел source_arn триггера шлюза API в моем ресурсе Lambda. Не уверен, как SAM сравнивается с Terraform, но, возможно, вы можете изменить сценическое имя или просто попробовать эту технику устранения неполадок, которую я пробовал.
Моя публикация SO: AWS API Gateway и функция Lambda развернуты через terraform - Выполнение не выполнено из-за ошибки конфигурации: неверные разрешения для функции Lambda
Та же ошибка, и решение было простым: снова очистить и применить сопоставление "Лямбда-функция" в настройках интеграции API-шлюза.
Мое отображение выглядит так: MyFunction-894AR653OJX:test где "test" - это псевдоним, указывающий на правильную версию моей лямбды
Проблема была вызвана удалением "теста" ALIAS для лямбды и его воссозданием в другой версии (после публикации). Кажется, что шлюз API внутренне все еще ссылается на "старый" экземпляр ALIAS. Можно было ожидать, что матч проводится чисто по имени...
Столкнувшись с той же проблемой, я понял, что проблема заключается в следующем: API-шлюз не может вызвать лямбда-функцию, так как я не видел журналов CloudWatch для лямбда-функции.
Итак, сначала я прошел через консоль API Gateway и в рамках запроса на интеграцию дал полный ARN для лямбда-функции. и он начал работать.
Во-вторых, через 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"
Я была такая же проблема. Я сначала изменил интеграцию на макет, то есть отключил тип интеграции от Lambda, а затем после одного развертывания снова установил тип интеграции на lambda. После этого он работал безупречно.
Я надеюсь, что это помогает.
В моем случае у меня был неверный путь для конечной точки отдыха, указывающий на то, чего у меня не было. Исправление пути, чтобы указать правильный путь, решило мою проблему. Пример моего правильного пути в рамках SAM:
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
Путь: /something/{value1}/{value2}
I had the same problem so I deleted then created the stack and it worked.
Похоже, что « Выполнение не удалось из-за ошибки конфигурации: недопустимые разрешения для функции Lambda » — это уловка для нескольких вещей:D
Я развернул стек с шаблонами CloudFormation и столкнулся с этой проблемой.
Я использовал сценический псевдоним в
SourceArnдля
AWS::Lambda::Permissionсегмент.
когда я изменил это на
*AWS немного более четко указал причину, которая в моем случае оказалась недействительной.
Handlerссылка (я использовал Java, обработчик переместил пакет) в
AWS::Lambda::Functionраздел.
Кроме того, когда я попал в свой API GW, я получил это сообщение
{
"message": "Internal server error"
}
Только когда я был за консолью и отправил полезную нагрузку в качестве теста для ресурса, я получил ошибку разрешений.
Если я проверю журналы Cloudwatch на наличие API GW, когда настрою его, то действительно упомяну истинную причину, даже если имя этапа указано явно.
Lambda execution failed with status 200 due to customer function error: No public method named ...
Документация для разрешений лямбда-ресурсов AWS показывает 3 уровня доступа, которые можно фильтровать или использовать подстановочные знаки, /*/*/*, что задокументировано как $stage/$method/$path. Однако их пример и большинство примеров в Интернете используют только 2 уровня, и я бился головой о стену, используя 3 только для получения отказа в доступе. Я переключился на 2 уровня, и лямбда создала триггер. Будем надеяться, что это спасет кого-нибудь от удара компьютера об стену.
В моем случае я получил ошибку, потому что функция Lambda была переименована. На всякий случай перепроверьте свою конфигурацию.
Технически сообщение об ошибке было правильным — функции не было, а значит, и разрешений. Полезное сообщение было бы, конечно, полезным.
У меня была аналогичная проблема, и я использовал Terraform. Ему нужна политика с "POST" в ней. По какой-то причине политика /*/ (подстановочный знак) не сработала?
Вот политика и пример terraform, которые я использовал для решения проблемы.
Большое спасибо всем выше.
Вот как выглядела моя политика JSON в отношении лямбда-функций и терраформа:
{
"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}"
}
В моем случае я использовал лямбда-путь, который не начинается с «/», напримерPath: "example/path"в моемtemplate.yaml. В результате AWS генерирует неверное разрешение для этой лямбды:
{
"ArnLike": {
"AWS:SourceArn": "arn:aws:execute-api:{Region}:{AccountId}:{ApiId}/*/GETexample/path/*"
}
}
Поэтому я исправил это, добавив '/' к моему лямбда-пути в шаблоне.