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.
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 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.
Background: On Azure (we're in the process of moving from azure to aws), we have everything organized into resources groups. By default no one can do much in the prod subscription(account), but based on the team asking for a provisioned resource, a team member gets stamped as the "owner" of the resource group, which just gives him/her full access to that resource group, and can add/remove other members as they see fit. This allows us to set up a very fine-grained set of access controls where each team ultimately decides whats allowed and not - not based on groups but based on users getting access to resource groups (in which instances and other resources exist).
Now that we're moving to AWS I had hoped to use the SAML integration to provide access (we're running Auth0 in front of AzureAD, but this should be the same for any saml/federated aws setup I think).
My problem is that with SAML AWS doesn't really "see" each individual user - they're not auto-created in IAM at first logon or anything, so the only "security boundary" I have to work with are the groups I send into AWS, which I can assign to IAM roles.
This is a problem, because 1)the user has to select the desired role at login (if member of more than one), and 2)each role setup is a manual task which requires me to configre AzureAD, saml claims in auth0 and finally IAM roles in AWS. The latter is obviously something I can automate, but still.
Here's the core of my problem:
Say that I have 2 EC2 instances in AWS: DB and Web. I have 3 users, AdminPete, DBDave and WebWilson. I'd like to be able to give Pete full access to both instances, while Dave and Wilson gets access to "their own" ec2 instance. As far as I can see, I would have to configure two IAM roles (DB and Web), and require Pete (who has access to both) to choose his role at login. This is a super-simple example, but it doesn't really scale well at all.
I'm curious to hear how you guys are doing access control in aws - my goal is to be able to create a very fine-tuned setup using tags or some other mechanism. The official aws documentation only deals with getting saml configured (which is easy enough), but very little about real-life permissions management.
The core of the problem (imho) is that unlike "regular" iam users, I can't attach an iam policy or a group to a single user when that user is federated - I can only attach the policy to the federated role as a whole.
Any pointers appreciated! At this point I'm considering just not using saml at all for our aws stuff so that we can use fine-grained iam policies to manage permissions in a more flexible manner.
We have multiple AWS accounts (about 15-20), one AWS account per client that we are managing, each account having VPC having dedicated setup of instances. Due to regulatory requirements all accounts needs to be isolated from each other.
What is the best way to manage account credentials for these AWS accounts? Following is what I am thinking
-For any new client
Create a new AWS account
Create AWS IAM roles (admin, developer,
tester) for newly created account using cloudformation
Using master
AWS account, assume roles created in step 2 to access other
accounts.
Is this the right approact to manage multiple accounts?
Thanks in advance.
Facilitating IAM Roles is a very common and (I think) the right approach to manage authentication for multiple accounts indeed, AWS has just recently released resp. updates that greatly help with this, see Cross-Account Access in the AWS Management Console:
Many AWS customers use separate AWS accounts (usually in conjunction with Consolidated Billing) for their development and production resources. This separation allows them to cleanly separate different types of resources and can also provide some security benefits.
Today we are making it easier for you to work productively within a multi-account (or multi-role) AWS environment by making it easy for you to switch roles within the AWS Management Console. You can now sign in to the console as an IAM user or via federated Single Sign-On and then switch the console to manage another account without having to enter (or remember) another user name and password.
Please note that this doesn't just work for the AWS Management Console, but also with the AWS Command Line Interface (AWS CLI), as greatly explored/explained in by Mitch Garnaat in Switching Roles in the AWS Management Console and AWSCLI.
Furthermore, Mitch has followed up with a dedicated new tool 'rolemodel' to help with setting things up pretty much like you outlined, which you might want to evaluate accordingly:
Rolemodel is a command line tool that helps you set up and maintain cross-account IAM roles for the purpose of using them in the new switch role capability of the AWS management console. These same cross-account roles can also be used with the AWSCLI as described here.