For small CloudFormation and CodePipeline templates we could "try - test" to get least privilege IAM Policy for the roles required.
This usually involves:
Starting with a minimal policy
Creating the stack
It fails with - stack doesn't have rights to someService:someAction
Add the service action to the policy
update stack and try again
This approach is too time consuming for larger CloudFormation Templates.
How are you developing Least Privilege IAM Policies?
Ideas:
Allow "*" and then scrape cloudtrail for events and build map for listed events to their equivalent roles - then reduce the roles to only those listed in the cloudtrail logs.
If you can isolate actions down to a user name this helps
https://github.com/byu-oit-appdev/aws-cloudwatch-parse
Access Advisor
Grant least privilege is a well-documented IAM Best Practice. The documentation recommends incrementally adding specific permissions, using the Access Advisor tab to determine which services are actually being used by an application (presumably using a broader set of permissions during the testing phase):
It's more secure to start with a minimum set of permissions and grant additional permissions as necessary, rather than starting with permissions that are too lenient and then trying to tighten them later.
Defining the right set of permissions requires some research to determine what is required for the specific task, what actions a particular service supports, and what permissions are required in order to perform those actions.
One feature that can help with this is the Access Advisor tab, which is available on the IAM console Summary page whenever you inspect a user, group, role, or policy. This tab includes information about which services are actually used by a user, group, role, or by anyone using a policy. You can use this information to identify unnecessary permissions so that you can refine your IAM policies to better adhere to the principle of least privilege. For more information, see Service Last Accessed Data.
This approach is similar to scraping CloudTrail for API events generated by a specific IAM Role/application, though the latter might be more difficult to filter through the entire event stream in order to find the relevant events, while the Access Advisor list is already filtered for you.
Related
In the spirit of providing least privilege permissions I often find myself hunting down required permissions to complete a specific task or providing others with access. Access denial messages in AWS are usually pretty good and list the required permissions. However other times the error message can be vague, especially when one service is dependent on another. Is there a better way than trying to complete an action and granting required permissions one by one? Does a list or some sort of tool exist?
AWS now has AWS Access Analyser that can be used to generate IAM policies based iam user/roles.
Here is the documentation: https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-generation.html
You can also use AWS CLI as well to generate policies based on IAM activity:
aws accessanalyzer start-policy-generation --policy-generation-details
and then, get the generated policies:
aws accessanalyzer get-generated-policy --job-id <>
another way, you can use user's access activity from AWS console and see what that user has been using and not using, and on basis of that you can create your policies.
I understand the resources and identity iam policies and im trying to restrict access to a group or user to only the resources this group or user will create.
Note the resources are not yet created, so i dont have a resource arn for the ec2/s3/ecs etc. i can use in the policy definition.
I have tried to create a policy with all actions on ec2 and restrict it to a resources set to a specific group but i have an error message stating the resources are not set properly
Thanks a lot for your time and consideration
This isn't really a question anyone can answer properly. So here are a few pointers to get you going in the right direction;
AWS Service Control Policies - https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples.html and https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html
AWS Control Tower - https://docs.aws.amazon.com/controltower/latest/userguide/what-is-control-tower.html
AWS Policy Generator - https://awspolicygen.s3.amazonaws.com/policygen.html
All that being said, I'm not aware of a way to do what you are asking. Any AWS account is designed to be a platform for the organisation, not an individual use case. It's top down, not bottom up.
If User X wants their own separate playground, set them up with their own Account under the main Organisation, but you probably won't want to do this per user, more groups/teams of people in most organisations.
I have an IAM role with AdministratorAccess, but when I upload a custom template to AWS CloudFormation, I get the following error:
Operation failed, ComputeEnvironment went INVALID with error:
CLIENT_ERROR - You are not authorized to call EC2 Describe operations.
It is required to perform CreateLaunchConfiguration operation.
All the other resources seem to complete successfully, so I'm not sure if there is some sort of role delegation taking place?
It is possible that you are affected by Service Control Policies (SCPs) or by Permission Boundaries or even other policy types.
Identity-based policies
Resource-based policies
Permissions boundaries
Organization SCPs
Access control lists
Session policies
Regarding SCPs:
An SCP restricts permissions for IAM users and roles in member
accounts, including the member account's root user. Any account has
only those permissions permitted by every parent above it. If a
permission is blocked at any level above the account, either
implicitly (by not being included in an Allow policy statement) or
explicitly (by being included in a Deny policy statement), a user or
role in the affected account can't use that permission, even if the
account administrator attaches the AdministratorAccess IAM policy with
/ permissions to the user.
Also see How to use service control policies to set permission guardrails across accounts in your AWS Organization
As this article states,
The member accounts of an AWS Organization are unable to see the SCPs
that have been applied to them. Further, when actions are denied,
there is no way to know whether that is due to an IAM policy, an SCP,
or something else (ex. session policy, IAM boundary, resource policy).
This means there will be no indication in the error message from an
API call or in the CloudTrail log to show what denied the call. This
can make debugging issues difficult.
This article has some useful diagrams that show the different things that could be affecting/limiting the access.
I've been working on this problem for four days and finally came up with a solution that I think resolves it.
There are two kinds of CDK bootstrap: legacy and modern. Legacy is the default.
There appears to be a bug in the legacy bootstrap that affects some accounts and not others. I was able to verify that the same code worked for me on one account but produced the exact symptoms of this problem on a newly created account.
If you are not stuck with legacy bootstrap for some reason, just convert over to modern bootstrap. That should make the error (and the reason for the error) go away.
The instructions are here: https://docs.aws.amazon.com/cdk/latest/guide/bootstrapping.html
Basically, you have to set an environment variable before you call cdk bootstrap, and then you have to change either some code or some configuration in your project.
It is not intuitive that this feature exists in the CDK at all, nor that it would be the fix for this particular problem. However, it cleared it up for me. Maybe it will do the same for others.
I have users that have been added by other admins in my AWS account. I am afraid that these users might get deleted by other people.
Is there a way to add a description to an IAM user?
I don't see any way to add description/tag when you create an IAM user. One suggestion is to create a IAM group for each admin and add the user to the admin's group when a user is created/added. You can have group(s) with no policy attached.
There is currently no way to add a description to a user. There are a number of better ways to solve your core issue however. Some of the IAM Best Practices specific to your use case include:
Use AWS Defined Policies to Assign Permissions Whenever Possible - AWS-managed policies are designed to support common tasks, such as deleting and creating users. Assign these policies to the users that need them.
Grant Least Privilege - Granting only the permissions required to perform a task. Determine what users need to do and then craft policies for them that let the users perform only those tasks. This is probably the most important factor in preventing users from being deleted accidentally.
Monitor Activity in Your AWS Account - You can use logging features in AWS to determine the actions users have taken in your account, including deletion of users either accidentally or on purpose. Two very useful tools you should be using in this regard include:
AWS CloudTrail - CloudTrail provides event history of your AWS account activity, including actions taken through the AWS Management Console, including user deletions.
AWS Config – Provides detailed historical information about the configuration of your AWS resources, including your IAM users, groups, roles, and policies.
As you can see, utilising the built-in tools that AWS provides can assist you in preventing administrators from deleting users unnecessarily.
As a workaround, you can add a TAG to your user with its key named "DESCRIPTION" and put in the description as a value. Note that for the value, you are very limited to the characters you can use. For instance, you cannot use the apostrophe ('). But it is better than nothing.
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.