I would like to secure a public lambda on my website. The users will not be authenticated when they access it. Any ideas how to do this ?
Jim
Amazon Lambda functions are not available to the public without authorization. Invoking Lambda requires AWS credentials. Unauthenticated users cannot directly access Lambda. The exception is if you are using API Gateway in front of your Lambda functions.
Access to AWS Lambda requires credentials that AWS can use to authenticate your requests. Those credentials must have permissions to access AWS resources, such as an AWS Lambda function or an Amazon S3 bucket.
Authentication and Access Control for AWS Lambda
Control Access in API Gateway
This link would be helpful with screenshots given.
Fix the issue using this link
Ideally issue is that access is give with * in resources or any of the policy statement which is causing this issue.
Related
I have a vue.js/aws-nodejs/mongodb-atlas website.
To lock things down better, I'm switching the mongodb-atlas database to VPC peering with lambda. That works just fine. But the other aws services now are giving me problems. They tend to just hang and never return.
I understand that I should use vpc endpoints specific to the aws services to make them work, but they are not consistently working or do not exist. Here's what I have:
lambda -> aws secret manager using secretmanager endpoint: works fine
lambda -> invoking other lamdas using lambda endpoint: works fine
lambda -> s3 does not work with interface endpoint, but does work with gateway endpoint.
lambda -> aws ses using smtp-email endpoint: hangs
lambda -> aws cognito admin functions (such as adminCreateUser), cannot find a cognito endpoint type: hangs
I have created a separate, non-vpc lambda that calls the SES api. My vpc lambda invokes this non-vpc lambda with parameters to send email.
This does work, but seems kludgey. My old non-vpc code worked fine. Before calling ses or doing anything dangerous, I checked custom permissions in my database. But this new non-vpc lambda does not have access to the database and therefore is missing this check close to the api call. This non-vpc lambda feels like potential weapon of mass destruction.
Apparently, I could use a NAT gateway. But a NAT gateway is expensive, especially if I want redundancy. And using the public internet defeats the purpose of using a vpc in the first place.
Why is the smtp-email endpoint not working while secretmanager and lambda endpoints do work?
How can I call cognito admin functions from a vpc-based lambda if there is no cognito endpoint type?
If there is no available endpoint type for a specific aws service (such as cognito), does that mean a NAT gateway is required?
Are lambda functions without an apig interface safe from being invoked by hackers over the internet?
Is using a non-vpc lambda to access aws services from a vpc lambda actually a good idea?
Should I just use a NAT gateway?
I have created a REST API using lambda and API gateway.
I want to give access for this API to another lambda function which is running in another AWS account.
I was thinking to create IAM based authorisation for this API. But I am not sure if this cross-AWS account based IAM authorisation is feasible?
Any better suggestions?
You can assume a role in the target account and then invoke the lambda directly using the temporary credentials. This method does not require an integration with API gateway.
You can also use IAM Authentication from anywhere if the API is publicly available. You will have to store the designated credentials.
Reference:
https://aws.amazon.com/premiumsupport/knowledge-center/lambda-function-assume-iam-role/
I have a lambda function which is accessible via the AWS API, I have got a link from the API which if hit will call the Lambda function, how do I restrict the access to this link such that it's not accessible to public?
AWS API Gateway provides a way to restrict access to the resources.
You just need to enable it in API Gateway Console.
Click on the resource method -> Method Request -> Settings -> Authorization
And select AWS_IAM
Then you can access the API with access key and secret key only.
AWS Documentation for your reference.
Screenshots for your reference
When using API Gateway to proxy AWS services such as S3 works great.
However it would seem that security is an afterthought. The execution role that is used for AWS Service integration seems to leave open the integrated service when using a customer authorizer.
The Custom Authorizer in API Gateway returns a principalId (e.g. a userId) and an IAM policy document. How could one build an IAM policy for the execution role of the service integration which would require for example the userId/principalId to be in the path of an S3 object.
I.e. using a custom authorizer + S3 integration how do you secure object access to only a particular key space where the principalId is part of an object tag or path?
http://docs.aws.amazon.com/AmazonS3/latest/dev/object-tagging.html or http://docs.aws.amazon.com/AmazonCloudWatch/latest/events/policy-keys-cwe.html
I was having the same problem. Here is how I solved it with the path.
Assume user1 need to access their data and their space is
domain/user1/object1
domain/user1/object2
In the custom Authorizer you can return policy that the user can access only domain/user1/*. You can use any pattern you want and organize the storage to whatever namespace you want. If you want to expand namespace for multiple users you can do access to
domain/user1/*
domain/managers/*
And APIGateway will take care of the rest. If the user tries to access anything other than the above URL paths, the user will get 403 forbidden.
Followed the documentation from AWS and works perfectly,
http://docs.aws.amazon.com/apigateway/latest/developerguide/use-custom-authorizer.html
In Addition, if you want authentication I would recommend CloudFront signed URL and Cognito.
My application uses Cognito user pools to restrict access so that each user may access their own personal folder read/write in a "private" bucket. In a "public" bucket it is the same, except that everyone has read access to everything and write access only to their own folder. This all works fine when accessed via the JavaScript S3 SDK.
I am now trying to implement access via the API Gateway talking to a Lambda function which accesses S3.
The problem is that it appears that the Cognito Userpool identity is not being used by the Lambda function. If I give the Lambda function role total S3 access then the function is able to access S3 fine and the function works. If however I have the role policies in place to restrict by Cognito Userpool ID as described above, the I get access denied.
It appears to me that the Userpool Cognito Identity is not what the Lambda function is using.
Can anyone suggest the correct configuration for this setup?
thanks
API Gateway and Lambda do not automatically support this use case.
The Lambda function is running with the identity of it's execution role, thus its context won't contain the identity attributes from the Cognito user pool. (The context object in the Lambda function contains the context from Lambda's perspective.)
API Gateway exposes the Cognito user pool identity information via $context.authorizer.claims variable within API Gateway. To access this information from within your Lambda function, you must modify your body mapping template in API Gateway to pass the desired data from $context.authorizer.claims to your Lambda function via the request body. You're Lambda function then reads this information from the request body like any other field.
In this scenario there is no mechanism to automatically restrict permissions to S3 buckets/object on a per Cognito-user basis. You could implement logic within your Lambda function to enforce it using custom code.