I have a policy that allows the Invoke action on a function. I tried to invoke this function using lambda.invoke() (using the aws javascript sdk) and got a 403 to say that I did not have permissions to perform the action InvokeFunction on the function. I then changed my policy to allow InvokeFunction (and removed Invoke) and only then was I able to invoke the funtion.
If allowing Invoke does not give permissions to invoke a function, then what does it allow you to do.
Related
I'm creating an Axios call to an API hosted on APIGateway with no Authorizer etc. I'm able to access the lambda via a direct postman request and also on the service lambda when it's ran in offline mode, such as:
https://localhost:3000/my/api
However when i run it on the dev stage:
12345.execute-api.eu-west-1.amazonaws.com/my/api
I'm getting a a 403: Forbidden error thrown back.
I've seen comments from other posts where they needed to append the staging environment at the end of the request but this isn't the case in this instance as it's just creating a default endpoint and all other lambdas within this service can be hit when ran on dev, it's just this one that makes a call to another APIGateway API.
The calling API is behind an authorizer with a wildcard policy so should allow all traffic and I'd like to reiterate, it works on both localhost and a direct call to the invoked api.
I'm wondering if it's something to do with the policies attached to it but I've set them all to be wildcarded as well so it should allow everything.
Any ideas would be really helpful, I've been wracking my brains over this all day.
Edit: The authorizer has no policy denying access to the API, same as the resource policy.
There are two common reasons why an API Gateway REST API with a Lambda authorizer returns a 403 error:
The Lambda authorizer function returns an AWS Identity and Access Management (IAM) policy document that explicitly denies access to the caller.
https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-lambda-authorizer-output.html
The second reason will be, The API has an attached resource policy that explicitly denies access to the caller.
https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-resource-policies.html
If both are in place, please update the question with those details.
The scenario is :
I have a Rest api gateway which when triggered invokes a lambda which processes the request and returns the repsonse.
This api endpoint is public.
I have another lambda which will call this API gateway/endpoint and obtain response from it.
Now the queries :
I am directly calling the invoke url of api just like any other api. So is this the right way to do so?
When I put the invoke url in browser address bar, it is giving missing authentication token.
How to actually call the url in calling lambda, i mean how to pass tokens; in Node.js ?
Thanks 😊
Well, the questions are quite wide enough. I'm trying to answer as much as possible.
First, the design you are following of Rest API -> Lambda, it is called 'Integration Type' is 'Lambda function' and use 'Use Lambda Proxy integration'.
Please take a look on the documentation here and an example here
Go through the document I believe you will understand in-out of this model. At high level, this model API Gateway is passing through request and response and you (Lambda) will handle everything.
Question 1:
I am directly calling the invoke url of api just like any other api. So is this the right way to do so?
[Answer] There is nothing wrong with this model. And yes, you can call this API (Lambda proxy) as any Rest API.
Question 2:
When I put the invoke url in browser address bar, it is giving missing authentication token
[Answer] Please check the setting of your API. As the below screen-shot, my api is using Cognito as Authorizer. It means consumers need to provide 'Token' (oAuth2 for example) when calling the API. You can use either Lambda authorizer or Cognito authroizer. It's up to you.
And if you are not requiring any authorizer, you can set it as NONE so there is no authentication token require for your API.
In short, the message you are getting now it means your API is having an 'Authorizer' and you are not sending token along with request.
Question 3:
How to actually call the url in calling lambda, i mean how to pass tokens; in Node.js ?
It is pretty common. You can google it like 'oAuth2 in Node.js', it will give you tons of examples
https://resources.infosecinstitute.com/securing-web-apis-part-ii-creating-an-api-authenticated-with-oauth-2-in-node-js/
https://stormpath.com/blog/talking-to-oauth2-services-with-nodejs
I hope it helps. Otherwise, leave your comments and questions.
Thanks,
I'd like to generate a custom policy that provides fine grained access to DynamoDB tables inside an AWS custom authorizer. Is this possible?
In serverless, my configuration looks like this:
functions:
APIAuthorizer:
handler: src/services/auth/handlers.apiAuthorizer
cors: true
GraphQLAPI:
handler: src/services/graphql/handlers.apiHandler
events:
- http:
path: "/api"
method: post
cors: true
authorizer:
name: APIAuthorizer
type: request
resultTtlInSeconds: 0
I've verified that my custom authorizer is being called, and that various permissions it generates (sts:AssumeRole, lambda:InvokeFunction, execute-api:Invoke, and others) are required for successfully invoking the API handler. So my custom authorizer is working and the result it provides is necessary.
However, when the authorizer includes dynamodb permissions, e.g., a statement like
{ Effect: "Allow", Action: "dynamodb:", "Resource": "" }
my API handler (the GraphQLAPI function) fails with a message like
User: arn:aws:sts::<myaccountid>:assumed-role/<mydefaultrole>/myservice-mystage-GraphQLAPI is not authorized to perform: dynamodb:Query on resource: arn:aws:dynamodb:us-east-1:<myaccountId>:table/<mytable>/index/<someIndex>
(I noticed the complaint is about an index permission, so also tried adding specific permissions for that index and/or for all indexes, but this has no effect.)
The bottom line, after many different attempts, is that dynamodb permissions issued by the custom authorizer are completely ignored. My lambda node.js code is using the AWS node SDK, which should be picking up permissions from the instance environment. I assumed this would include permissions generated by the custom authorizer.
Finally, I noticed that the AWS javascript SDK documentation on how credentials are loaded says only "The execution role provides the Lambda function with the credentials it needs to run and to invoke other web services". I.e., it doesn't mention the dynamically generated credentials issued by the custom authorizer.
This seems to explain the behavior I'm seeing. My API handler only has permissions from the statically defined execution role (the error message indicates that too), and isn't granted permissions generated by the custom authorizer.
Is there anyway to use the permissions my custom authorizer generates inside my API handler?
I think you misunderstood the IAM policy output from Lambda authorizers. The purpose of the IAM policy output from the authorizer is to reflect what the outcome should be for API gateway with respect to continuing to process the request.
The policy returned is not necessarily applied to the invoked function, but applied to the invocation of the function. It merely tells API Gateway which APIs the requesting user is authorized to access.
If you wish to give the API functions being invoked specific access to resources such as DynamoDB tables, or any other AWS resources, those have to be configured in the role assigned to the Lambda function. Otherwise, you may be able to specify a role that the Lambda function to be invoked would assume that grants it additional permissions. This role can be passed via the context parameters from the authorizer.
I am fairly new to lambda and trying to wrap my head around it. I created a basic hello world function and invoked it through
aws lambda invoke
My question is
Dont I have to create an API gateway and expose the lambda function through the API gateway for it work.
How does aws lambda invoke if I have not created a gateway and exposed the function?
You do not have to necessarily create API gateway for invoking lambda function. Every lambda function is already available to be accessed via Amazon's Web Service using API:
POST /2015-03-31/functions/FunctionName/invocations?Qualifier=Qualifier HTTP/1.1
See http://docs.aws.amazon.com/lambda/latest/dg/API_Invoke.html for more details.
However, the above API expects that the request payload is signed using aws signature version 4 . The CLI call aws lambda invoke automatically takes care of that piece once you have configured valid access and secret keys.
The API Gateway in front of lambda allows you to add:
Custom resource names
Custom authentication schemes (even no authentication if desired)
Custom way of sending payload
and more...
In summary, API Gateway gives you more control over the API resource and can even abstract the user from internals of AWS API.
I've successfully configured IAM-authenticated access to my Lambda function with AWS API Gateway front-end, but unable to find how to pass IAM user identity to my Lambda function.
I need exactly IAM user identity and can not run Lambda function under calling IAM-user credentials.
All I need - is to get calling IAM-user identity in my Lambda function.
Is there option for that?
Support for accessing identity and other information from the Amazon API Gateway request context hadn't been available when you posted the question, but recently been added, see Announcement: Context Variables:
You can now access context variables from within mapping templates to retrieve contextual information about the API call. You can access data such as stage, resource path, and HTTP method, as well as information about the identity of the caller. This information can then be passed along to your backend integration using the $context variable. [emphasis mine]
The referenced documentation on Accessing the $context Variable features a $context Variable Reference and there are various $context.identity.* parameters that should address your use case.
Cognito Identity
As outlined in Soenke's answer to the OPs similar question in the Amazon API Gateway forum, there is an as of yet undocumented integration parameter that results in the Cognito identifier being included in this $context.identity.* context variables:
in order to have the Cognito (not IAM!) IdentityId and IdentityPoolId
available in Lambda, you have to enable "Invoke with caller
credentials" on the API Gateway "Integration Request" page of the API
GW Resource. This results in a new context struct "identity"
(containing "cognitoIdentityId" and "cognitoIdentityPoolId" being
passed to the Lambda function).
You can use Cognito with a "public" pool id, then attach role to the Cognito pool id, the role being accessing your Lambda, I think it is called InvokeLambdaRole or something
AWS.config.credentials = new AWS.CognitoIdentityCredentials({
IdentityPoolId: 'REGION:YOUR_POOL_ID',
});
Use AWS STS to get temporary credentials with limited privileges. After that you can use API Gateway with AWS_IAM authentication, then end point will invoke the Lambda methods for you. Or you can invoke lambda directly with the credentials you got, but then again you have to attache the right roles for the identity pool you created.
NB: Put strictly minimum roles on your pole, that is a publicly available id, every body can use it to get a temporary or a fixed (to track users accross devices) user_/app_ id.