Let's assume we have a nice, little cloud account running simple workloads. We have two user types accessing this account:
System accounts to access specific resources (CI/CD, DB access, etc.) with very fine-grained permissions
Two or three user accounts to manage the cloud account and everything on it (a.k.a. admins) - with pretty much full access
To secure the user accounts I want to enforce multi-factor-authentication on a global level. On MS Azure the AAD admin can enforce MFA on a per-user-level (on https://admin.microsoft.com). That feels straight-forward to me.
On AWS this seems much more cumbersome:
The IAM user management view only provides MFA configuration options for the current user.
AWS suggests to enforce MFA on a per-policy basis (see AWS docs).
This Stackoverflow thread extends AWS' approach to create a BlockMostAccessUnlessSignedInWithMFA policy. But still: per-user MFA is managed in policies and the custom BlockMostAccessUnlessSignedInWithMFA policy feels like a workaround.
Is there a more straight-forward way to do this on AWS IAM User management?
If not, am I missing something why the Azure AD's approach cannot work on AWS?
Any idea is welcome
Related
I am trying to understand why you need IAM "roles" to access a resource in a different IAM account, and why AWS can't just do the same thing with IAM groups.
Whenever I ask people this question the conversation just seems to go in circles:
Them: "To grant access to a resource to users in another IAM account, you have to give them permission to assume an IAM role, and then grant that IAM role access to your resource."
Me: "I understand that, but why can't you just create an IAM group that can access that resource, and then add those users from the other account to your IAM group?"
Them: "You can't add users from another AWS account to an IAM group in your account."
Me: "I understand that too, but why does AWS only let you do cross-account permissions like that by using roles? Why wouldn't it make just as much sense for AWS to let you create an IAM group and then let you add IAM users from other accounts into that group?"
There's probably some simple one-sentence piece of information that explains why it has to be this way, and once someone tells you, it all makes sense, but it's not in the documentation and I don't know what it is. What is it?
I would say security is main reason. IAM roles provide only temporary credentials. Using such credentials whenever possible is good practice for security reasons.
Off course you can also create IAM user in your account, and give the associated access keys to people form the other account. And sometimes this is preferred, e.g. to enable read access only to some resources. But the issue is that IAM user credentials are permanent, unless manually disabled or deleted. For security reasons giving away permanent credentials to your account is not a recommended practice.
From docs:
We recommend using this approach to enforce the principle of least privilege. That means restricting the use of elevated permissions to only those times when they are needed for specific tasks. With roles you can help prevent accidental changes to sensitive environments, especially if you combine them with auditing to help ensure that roles are only used when needed.
The one-sentence answer is that Amazon chose to do it that way.
From an operational perspective, it simplifies life considerably if you associate an access key with an account. The alternative is to specify an account separately with every request.
From an organization management perspective, trees are easier to understand than forests. What I mean by that is that everything branches off the account's IAM root. If you allow arbitrary users across the AWS universe to have access to arbitrary resources within arbitrary accounts, you end up with a management nightmare.
As a sidebar to that last comment, the early AWS services had resource-based policies. These are now discouraged in favor of identity-based policies, and newer services don't have resource policies.
Lastly, from a security perspective, a multi-tenant environment is a lot easier to control if you establish a hard wall around each tenant.
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.
I'm looking for something that can programmatically spin up instances for other AWS users after oauth. Is there something like this that Amazon provides? So they can just login with AWS account and then I can make AWS calls on their behalf.
Is there anything like this out there?
There's no logging in here. You need a cross-account role, supplied by the owner of the other account.
There is nothing like this.
It would have massive security implications.
Note that the primary entity in AWS is not the user, it is the "account." Accounts have users, and those users can only do what the account has authorized them to do.
For one AWS account ("mine") to allow another AWS account ("yours") to perform actions on behalf of my account (technically, not on behalf of "me"), I have to explicitly give you permission to do so, via IAM. One solution is to create a role with the necessary permissions and delegate access to you.
But this is unlikely to be something a well-informed user would permit, since you could easily run up substantial expenses for the user. Allowing such external access would not be a good practice.
There is, however, a way for users to launch your software on EC2 and optionally pay you a license fee billed on your behalf by AWS, through the AWS Marketplace, which is oriented towards a one-click experience for the user.
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.
For one of my business process I want to create IAM user for multiple application to access the same resource, I have thought of the following options:
Create 1 IAM user and use the credentials across the applications in the business
Create individual IAM user per application and use respective credentials
I went through https://aws.amazon.com/iam/faqs/ and it mentions that IAM user can be an application or a system.
I understand 1 has an advantage that it simplifies the process with only a single IAM user to manage.
But 2 makes the applications independent of each other and provides fine-grained control over credentials.
What is the best practice followed in creation of IAM in this case and why?
In general, AWS prefers creating individual IAM users for easier management and auditing. You can also revoke access to a specific app without affecting other system users. See IAM Best Practices.
I also quote from the AWS Security Best Practices whitepaper.
We strongly discourage the use of shared user identities, where
multiple entities share the same credentials.