We have a setup like this in AWS -
Step functions include few lambda functions that write to S3 buckets
S3 bucket is passed as an argument to lambda functions by the user
API Gateway is setup to invoke Step Functions and IAM Authorization is enabled
However, currently the step function and lambdas are invoked under the IAM role defined, but we want all lambdas to be executed as the authenticated user. So if the user invoking API does not have access to S3 bucket passed, the lambda should fail. How can this be achieved ?
One of the responsibilities of Amazon API Gateway is to be a facade for your backend (here Step function and Lambda functions) and to guard it from unauthorized invocation.
I see two options. The first is easy, the second is more proper way to have all constrols.
Don't give your IAM users permissions to call this API if they don't have permissions to access data in S3 bucket. Also, remove permissions to access Step Function and Lambda Functions. Apply the principle of least privilege.
Instead of using IAM Users, use Amazon Cognito to authenticate your users to your application. Attach Cognito as an Authorizer to your API. Your Lambda function can get information about the user via context input parameter. Use DynamoDB to store additional information about the user and add business logic to your Lambda to handle any special behavior.
Related
I have dozens of services each requiring access to their corresponding secret in AWS Secrets Manager.
I have implemented a solution of granular permissions to IAM roles of services so that each can access only their credentials. This creates neatly a least access pattern to services.
I want to implement an AWS Lambda to abstract away access to Secrets Manager secrets. If I have only one Lambda (per environment), how can I check that the IAM role invoking the lambda has permissions to access a particular secret? So to exclude the case of a service requesting access to another service's credentials.
I can always create one lambda per service and assign permissions to each service to only invoke their lambda (which only accesses the corresponding secret), but this seems quite inelegant...
AWS has a large number of buckets that different users have access to. And there is a lambda function that selects data from s3 and gives it to the client via the Api Gateway. The client has the opportunity to specify in the api request from which bucket lambda should make a selection. But how to check that he is requesting exactly the bucket to which he has permission?
In the iam policies, I can only indicate that it can access a specific api resource, but the resource is shared by everyone. In lambda authorizer, I can't get information about the user's rights and permissions (or can I?).
Please tell me how you can solve this issue. Which way to move?
P.S. This should be the authorization of users in amazon, I can't give them my JWT with my data.
It would be your responsibility to code the authentication and permission requirements in your own code. The person making the request via API Gateway is not an IAM User, so AWS does not recognise them and cannot grant access based on the normal AWS permission model.
Your code would need to:
Recognise and authenticate the user
Determine what resources (buckets) that user is permitted to access
Only provide access to permitted resources
How to do this is your decision. You should start with a way of identifying and authenticating the user.
I have API gateway set up in account A and I have linked my lambda in account B with my api method in account A (added the correct permissions to account B). It always used to worked perfectly.
Now when I tried to deploy a change to the api gateway it keeps saying "The policy of Lambda function must explicitly authorize the method or custom authorizer with a SourceArn condition for cross account integration".
I have checked multiple times, all the permission are there in account B on the lambda function. I even deleted them and added them again. If I add the permission for just the lambda function without the alias it works, but when I add my alias then I get the "The policy of Lambda function must explicitly authorize the method or custom authorizer with a SourceArn condition for cross account integration" error, but I can see the permissions for my lambda with the alias in account B.
What am I doing wrong?
I have a AWS Lambda function in production. Triggering it can lead to monetary transactions. I want to block the feature of testing this lambda through AWS console so that users having console access cannot accidentally trigger it for the purpose of testing which they can do on the corresponding staging lambda. Is it somehow possible?
First solution that I would recommend is to not mix production and other workloads in the same AWS account. Combine that with not giving your developers and users credentials to the production account.
Assuming that you don't want to do that, you could apply a resource policy on the Lambda function that denies all regular IAM users permission to invoke the Lambda function. Be sure that your policy does not deny the 'real' source in your production system (e.g. API Gateway or SQS or S3). You should also prevent your users from modifying the resource policy on the Lambda function.
Alternatively, if all of your IAM users are managed under IAM groups, then you could apply an additional group policy that denied all actions on the Lambda function ARN. Again, ensure that they cannot modify the group policy to remove this control.
Let's say I have this usecase where the user is allowed to read from certain dynamodb table and getObject and putObject privileges in the S3.
Following items I have been able to establish-:
1. User is authenticated against cognito user pool
2. On successful auth, access token sent to API gateway
3. custom auth blueprint is used to validate and generate policy doc
Now what I am not able to understand is where and how do I mention the table/S3 permission specifics.
I went through the following documents/blogs
https://aws.amazon.com/blogs/compute/introducing-custom-authorizers-in-amazon-api-gateway/
http://docs.aws.amazon.com/apigateway/latest/developerguide/use-custom-authorizer.html
https://mobile.awsblog.com/post/Tx3JK25U7Z9EUIU/Integrating-Amazon-Cognito-User-Pools-with-API-Gateway
However, I am still confused as to how and when will the policy document, created by the custom auth lambda, be used? and a clarification on the flow would be highly appreciated.
We actually just launched native support for Cognito User Pools, which will validate the JWT vended by Cognito. However this will just do a simple ALLOW/DENY decision (allowing if the token is valid), so there is no concept of fine-grained permissions.
For custom authorizers, the policy that you generate is cached and can apply to the entire RestApi (or all methods that use the same authorizer). The policy allows you to set up fine-grained permissions just like you would with an IAM User/Role.
One use case would be a group-based permissions setup where the custom authorizer determines who the caller is and assigns a group policy (ex. admin, readonly, blocked, etc.) in the response to the first API call with that token. Those policies would set fine-grained permissions on specific resource/methods in the API. Then on subsequent API calls to any other resource/method in that share the same authorizer, the group policy would be applied.
So the benefits are:
Fine-grained permission policies associate with users, like IAM Users/Roles.
Caching the policy for the entire RestApi reduces Lambda invocations (cost and latency benefit).