-
Notifications
You must be signed in to change notification settings - Fork 143
After add lambda function in x-amazon-apigateway-integration, don't have access to run test on AWS console #9
Comments
I am having the same problem. I am trying to make the simplest possible API, which takes a GET request to /test, and forwards it to a Lambda function. I can make it just fine manually with the web interface, but not with Swagger.
If I include the "credentials" parameter, I get:
If I don't include it, I get:
If I do include it, deploy the API and use the HTTP interface, I get a response:
Even though I do not understand what is the credential used for: is it a credential that the API gateway uses to call the Lambda function, or is it the credential that the Lambda function uses to execute? I don't think it's the latter, as isn't that already defined in the Lambda function configuration? If it is for the API gateway, I am guessing that using the web interface adds some magic credential. I feel dumb. :( |
I noticed that there was an extra quote after the
The Test gives "Invalid permissions on Lambda function". The Integration seems fine in the API Gateway Console:
But, when I go check the Lambda Console -> API endpoints, there are none specified. If I go back to the API Gateway Console -> Integration Request, click the Lambda Function field, do not change the name but just click Update, a dialog will appear:
Once I click OK, the endpoint becomes visible in the Lambda Console, and while nothing has seemingly changed in the API Gateway Console, the Test now works. So how do I do think linkage with Swagger? I have tried passing all kinds of roles in the credentials parameter, but they all return the same "API Gateway does not have permission to assume the provided role." |
Hi folks, First of all, I apologize for the sparse documentation - we are working on it! These concepts are more specific to the API Gateway service and not particularly related to the Swagger importer - you would run into the same issues using our API. I realize this can be difficult to set up, but luckily this is usually a one-time setup per account. I'll try to clear a few things up. There are currently 2 different ways to invoke a lambda function:
At a minimum, the role must have these actions allowed: ... as well as a trust-relationship defined for API Gateway: ... See http://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html
When you setup a method with a lambda function using the API Gateway management console, we automatically add a permission to the lambda function. However, the Swagger importer or the SDK does not add this permission - this is why you might see different results when using the console vs using the importer. When using resource-based permissions, you must explicitly update the policy on the lambda function so that API Gateway can invoke it from the specified API/resource/method combination. To see an example policy, attach your lambda function using the API Gateway management console, then use the Lambda API or CLI to view the function policy (See http://docs.aws.amazon.com/lambda/latest/dg/API_GetPolicy.html). You can then replicate this policy for APIs managed by the Swagger importer. Note that wildcards can be used for API ID, resource, method, etc. in the function policy. I hope this helps with the above questions. Another point - if you get 403 "Missing authentication token" when calling your API, it may be related to an error in the URL (api id/stage/resource path) or http method, rather than an auth error. We send 403 in all cases when the resource cannot be located. Please let me know if this helps! Cheers, |
This looks like a signature issue when calling lambda. I'll look into this and get back to you |
Hi rpgreen - I attempted to use the CLI to add the permission after I ran my swagger file. I get the same error as shown above. I ran the following command: Here is the policy entry after I ran get-policy. Thanks in advance. |
Thanks for the help, Ryan. I am just chiming in to let you know that I managed to get mine working. Indeed I was missing the trust relationship from the role, so API Gateway could not assume the role by itself. I have now gone back to reading the docs. |
We are actively looking into this. Can you confirm that you get the same On Thursday, August 6, 2015, John notifications@github.com wrote:
|
Yes
|
I just set up a simple example from scratch with a successful response from both the console test invoke and from curl. Swagger:
with the following policy for apiGatewayLambdaInvokeRole:
and the following trust relationship:
Are you able to reproduce this with a new API and lambda function? The error seems to be coming from lambda. Would you mind sending your lambda function execution role? |
If you can recreate this, please send the x-amzn-RequestId response header so I can investigate further |
Hi all, I found the issue in the swagger definition. Http method should be POST to invoke a lambda function, as per the Lambda API. See http://docs.aws.amazon.com/lambda/latest/dg/API_Invoke.html Change the http method on your integration to POST and this should work. |
I think I see what you mean - that while the API Gateway method is GET, internally it needs to send a POST to the lambda? I had been under the impression that the two methods had to match. I don't have a built swagger importer here at home, but I'll test first thing in the morning. Thank you for looking into this - it's been driving me crazy. |
That works perfectly. Awesome!!!! |
Thank you, works just as you said! |
I had a similar issue and it was because my uri read: |
I just reproduced this by copying an existing API into a new API and deleting the old one (which was instantiated via cloudformation). |
If lambda always needs POST requests, then would it make sense for |
The integration definition applies to Lambda, HTTP backends, and also other AWS services. Yes Lambda does require POST requests, but I don't believe it makes sense to go with that assumption behind the scenes. As to the previous comment on the URI missing '/invocations', I agree the format is complex and easy to mess up. We are working on improving documentation across the board. |
Im trying to make a declarative and repeatable way to deploy my entire AWS env and am struggling to wire the api gateway to the lambdas. When I do the following awscli command:
I get a response like this:
The Sid, I'm assuming is the Service ID. Is that needed to create this Policy? Also, How can I create this policy and apply it to the service before the service is created? Here is the general process Im thinking I need to do to get my api wired to the lambdas?
|
Yeah that's pretty much it. Few notes below: Source ARN identifies an API Gateway method and should be structured like this:
(Note wildcard (*) can be used for the value of STAGE) You may need to modify the importer code in order to dynamically build a list of the resource paths/methods and lambda functions to add the permissions. Or you could simply hardcode them into your add permission script, but that would need to be maintained when you change the API definition. Sid is the "statement ID" and must be unique - it's not related to the API. Keep in mind that there is a limit to the overall size of the function policy, so if you keep adding permissions to the same function you will eventually hit the limit. |
Related to #111 |
Thanks. I think I will write a bash script that pulls the path from the swagger file using jq (a bash json parsing tool) and do this for each path. Im wondering tho, which of those ARN sections can I add a wild card to? and which can I not? Can I create a policy like this:
Thus granting all methods to each lambda associated with the API. Does this present any real security concern (when a restful endpoint has invocation access to a lambda it's not linked to)? |
Does this present any real security concern (when a restful endpoint has invocation access to a lambda it's not linked to)? Yes, absolutely. I believe wildcards are accepted in any element, but I would strongly suggest to be as specific as possible when building the source ARN. At a bare minimum you should explicitly set the account ID and the API ID. Hope this helps. If you think your script could be re-used a PR would be much appreciated |
Ok, thanks Ryan. I'll consider adding a PR to importer. I have a local snapshot and I'll see If that might be a better solution with my timeframe |
The version of AWS SDK (1.9.6), that the aws-apigateway-importer is using does not support creating a policy via the |
Yeah that should be straightforward, go for it. Alternatively, if you wanted to use the CLI you could have any arbitrary version running in your environment. |
I wired in a Upgrading the sdk version worked fine:
Here is the ApiGatewaySdkSwaggerApiImporter code that I added (it looks at integration extenstion in swagger for a resourcePolicyConfig):
And here is the Provider configuration:
But I keep getting this error when invoking addPermission:
This is using the following integration config in swagger:
Any idea why I would be getting an Internal Error? My code matches up with the documentation; Example 2: Grant Amazon API Gateway Permissions to Invoke Your Lambda Function I'll see what happens when I try with awscli. |
That looks like a fault on the Lambda service side. Are you able to get it working with simple test input for source arn, etc? Your code looks good except that the source ARN should include the full resource path, not just the path part. Are you sure that the credentials used have IAM policy to allow them to add permission? This looks like a Lambda bug to me - I would suggest to follow up with the Lambda team with your stack trace: https://forums.aws.amazon.com/forum.jspa?forumID=186 |
I am able to get it working using awscli with the following command:
The response looks like this:
It looks like the bug is with the java sdk. |
+1 |
If you are using boto3 for adding an integration of lambda function to APIGatway, make sure httpMethod and integrationHttpMethod both are set to 'POST'. |
Has this been resolved? I cannot find a way to make it work using terraform. See here for details. |
I had a similar issue. I had to set "Use path override" but I chose another one.
|
I was finally able to get my API Gateway custom authorizer to work because of this issue, so thanks! But I wish this was simpler and in the AWS docs, would of saved tons of time, AWS needs to improve their API Gateway docs/experience, its quite frustrating. |
Removed
The text was updated successfully, but these errors were encountered: