I'm creating a serverless app using API Gateway and Lambda. When creating roles for my API. What is best practice, How granular should I get?
Should I create a new role for every resource?
Or every method?
Or for API Gateway and Lambda respectfully?
Its application specific, but the general rule is to follow AWS best practice and grant least privilege permissions for accessing your resources.
Following the AWS best practice, you:
Start with a minimum set of permissions and grant additional permissions as necessary. Doing so is more secure than starting with permissions that are too lenient and then trying to tighten them later.
More specific to your question. API Gateway don't have roles, they have resource policies. They are generally used to specify permissions regarding who/what can invoke your API. I would recommend checking out official AWS examples of such policies and model your policies based on them, which includes how detailed they are: API Gateway resource policy examples
Since in your setup, lambda is going to be accessing your other resources (e.g. S3, DynamoDB) you should specify its permissions to access these resources in its execution role.
If you have several lambda functions having same permission they can reuse the same role. Also if you want to use different roles, you may create IAM custom managed policies which you could attach and reuse across different roles.
Related
I am looking to add a user in AWS. I have a group with supportUser policy.
The thing is, he can create users and change passwords.
With supportUser policy, he is not able to view any payment information, billing or anything regarding the account.
I am looking for a policy that would only allow him to create a EC2 container, S3 storage and a database. Nothing more. Is there a way to achieve this?
AWS gives you options to create your own fine-grained policies or you can simply use managed policies. Managed policies provide a gentler introduction because AWS has provided curated policies for you. Managed policies are also updated periodically to incorporate new function or new services, as relevant to each specific managed policy.
See AWS managed policies for job functions or, more generally, AWS managed policies.
The simplest managed policies for your use case are probably:
AmazonEC2FullAccess
AmazonRDSFullAccess
AmazonS3FullAccess
Important note: each of these policies grants the user significant permissions over all EC2, RDS, and S3 resources so you may find them too permissive for your use case.
If you want more control then write your own policies. Start at Policies and permissions in IAM. You can also copy/paste the contents of a managed policy and then edit it down to just the permissions you want, and constrained to the resources that you want (e.g. to specific, named S3 buckets).
We have started initially by defining roles with admin access policy attached. But now we want them to have policy with only specific permissions that are minimum and does not create any issues for using these roles.
Looking at "Access Advisor" tab on each role under AWS IAM console, it gives good amount of information that exactly which AWS services getting used and permission level information only for EC2, IAM, Lambda, and S3 management actions services. But for rest of other AWS services, missing that what specific permission for that particular service is required.
Also not having AWS Organizations master account access as mentioned in this tutorial: Viewing last accessed information for Organizations.
So is there a way I can get the permissions level info for services other than EC2, IAM, Lambda, and S3 management actions?
Thanks.
So is there a way I can get the permissions level info for services other than EC2, IAM, Lambda, and S3 management actions?
Sadly, there is no such way provided by AWS. So basically its try-and-see approach to get what you want. You can try some third party tools, which may be helpful, such as zero-iam, but ultimately, you will need custom solution to match your requirements.
There is also IAM Access Analyzer which is different then Access Advisor. But its also limited to some services only.
I'm struggling to understand the practical differences between an execution role that can be assumed by API gateway to grant the permission to execute a lambda over a lambda resource-based policy.
For example, the documentation here provides an example of a policy that can be assumed by the API gateway to invoke a Lambda.
However, the API Gateway console will grant itself permission to access a Lambda via a lambda resource-based policy.
Both achieve the desired outcome of allowing the API Gateway to execute a Lambda. So is there a reason to choose one over the other?
Apart from the general use case / advantages of having resource-based policy that is explained pretty well here
does not have to give up his or her permissions to receive the role permissions
In this specific case, I have experienced 2 distintive advantages using Lambda's resource based policy over role
The creator of Lambda - API Gateway integration does not need to have access to IAM. No role created
Because no role is created, no role need to be cleaned up. The developer delete the Lambda function he created to play around and everyone can forget about it
I think one of the significant advantages of resource-based policies is that they can be applied to specific versions or aliases. This is unlike IAM roles, which cannot target a specific version or alias.
I manage the AWS security in my company.
We by default do not provide IAM role creation permissions to our developers.
But here is the problem, how should we handle this for developers who are using serverless framework to deploy their workloads?
Should we allow them to create IAM roles and have serverless framework to manage the permissions for those roles? or should we precreate the custom roles for this and ask developers to use that Role ARN in serverless.yml or should we use IAM permissions boundary?
Can some one please help ?
It's really hard to tailor the permissions needed by the serverless. In my opinion, the developers should have full AWS access at least to test environments in order to learn and experiment. If you are worried about accidental damage to production resources, you can only make changes to production via CICD tools. You may still have to temporarily grant permission to developers to do the initial configurations.
What you would want to do is use the Permissions Boundary feature provided by AWS. With this feature, the effective permissions the devs / serverless stacks would have is the intersection of the policies defined in the IAM role and the permissions boundary.
For example, lets say that you have allowed your devs to create IAM roles and policies for Lambda functions. You also have defined a permissions boundary with only S3 read access. Now if the devs were to create a serverless stack with Lambda permissions with the AdministratorAccess policy, they would have to include the permissions boundary in the role and the effective permissions that your Lambda functions would have is just S3 read access.
There is a good blog post explaining this implementation in CloudFormation you can modify it to work with Serverless templates. Hope this helps.
One developer friendly approach would be using several accounts, combined with locking down the production account more than the testing account(s) developers use.
As mentioned in #captainblack's previous answers, a Permissions Boundary can be one tool to restrict potential damage in production. We use it in addition to function specific roles / SAST scanning in our CI/CD environment and enforce all newly created roles to adhere to the defined boundary in production.
For the Serverless Framework you can implement it like this ([account] is your account id):
provider:
name: aws
runtime: python3.9
rolePermissionsBoundary: arn:aws:iam::[acccount]:policy/permission_boundary
This way all roles serverless creates will inherit the permissions boundary from the provider settings.
I can't seem to find support for a surprisingly relevant issue. There are 10's of AWS services, so I want an AWS policy that restricts our users to only EC2, RDS and API Gateway. How do I do this? Can I 'deny all' and only endorse these specific services?
When you create a new IAM user, the default is all permissions denied.
If you want all users to have the same permissions, create a group. Assign each user to the group. You can also create multiple groups for different types of users.
Amazon has predefined policies that grant varying levels of permissions for each type of service. Select the policies that apply to your goals to the group(s).
Very easy to implement.
You can also create custom policies that define basically anything that you want. IAM policies range from the simple to the very complex.
You'll need to create Managed IAM policies for all users.
Tutorial
Creating IAM Policies
Example Access policies
You can also create Explicit Deny rules
Test IAM policies