Hi got AWS and IAM profiles. Currently users have the option to setup their own MFA but it seems like there is no way I can see for the root user to enforce MFA on its users it gives access to. Surely given the current security issues this is something that should be promoted to enforce. Am I missing something here? Is there a way to enforce MFA on IAM users?
My understanding is that you can't really enforce it as "I want every IAM user in this AWS account to have MFA configured". This AWS blog post explains how to restrict actions of your IAM users based on the presence of MFA.
I would say that, in general, you should care about the security of your resources and make sure you don't expose anything to an entity that does not present MFA. This can be done by enforcing MFA (similar to the blog post linked above). The optics is slightly different: you don't care if some IAM user has MFA, you care that anyone accessing some resource presents MFA.
You can effectively set the following condition everywhere you need:
"Condition" : {
"BoolIfExists" : {
"aws:MultiFactorAuthPresent" : "true"
}
}
More information on the global condition aws:MultiFactorAuthPresent in the official docs.
P.S. I believe that, in the same way as you're able to force IAM users to change their console password on the first authentication, it could be a nice feature to be able to enforce the presence of MFA. You could try submitting a feature request on some AWS forum.
Related
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
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'm looking into the following. I have several AWS users in my account. Some users have console access and programmatic access. All users have a policy attached that enforces the use of MFA. For users that want to access AWS programmatically, this is a problem. For normal access, I know they can just add the token in the CLI. But the problem I have is when we run an automatic process from one of those accounts. You can't just add the MFA token in your code because the token changes, but the forced MFA policy prevents access to AWS which causes an error.
The only working solution I have now is using seperate users for concole access and programmatic access and only enforcing MFA on the console access user. But this is a silly solution and requires people to manage seperate user accounts.
Does anybody have a better solution? I tried to change the force MFA policy so it would only require MFA to work with console access or so it would require a connected MFA device, not an MFA login. But that didn't work.
Sorry if anything is unclear, English is obviously not my first language, please do ask if you need more details.
Thanks in advance!
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.
Ia m trying to enforce all users to setup MFA login when they sign up. Is this something that is possible in AWS and how or where are the instructions to do this?
Sort of. You can essentially block non-admin users from making API calls without using MFA. There's a section about setting this up in this AWS blog post. The blog post describes how to give someone access to setup MFA, and require MFA for every other interaction with the AWS API. I think this will require MFA to be used with calls from the SDK and CLI as well, so it might not be exactly what you want.
Also, I say this is only for non-admin users, because admin users would have the ability to go in and disable the MFA restriction on their account.
This is difficult to do because the MFA device needs to be setup and once you do that, you need to enter information from the device. Usually you have to enter two tokens in sequence to "synchronize" the device.
So you can't setup a virtual MFA for a user without the user. However, if you had a hardware MFA device (see https://aws.amazon.com/iam/details/mfa/) then you could setup the user and the device and then give the user the device.
It's not perfect by any means.
Yes, this can definitely be done! Of course, admin and root users are able to disable the policy, but if you so desire, you can also limit who can update or disable the policy. When the enforcement policy is in effect, when the user logs in the only thing they have access to do is to enable the MFA for their IAM user. Once they then re-login with MFA enabled, they have the access they've been issued with the IAM policies/group memberships, etc.
It is not possible to enforce MFA only in the AWS web console, because the web console is essentially a front-end to the APIs which the AWS CLI tool also accesses. Starting and managing MFA (and role) sessions on the command line is a rather convoluted process, so you may be interested in a utility whose 2.0 version I just released. It makes it very easy to start and manage MFA and role sessions. I have also included an example enforcement policy that has been carefully built to work with the utility. A companion script is also provided to make it easy to enable/assign an MFA device from the command line (e.g. for the users who don't have web console access).
You can find the utility, more information about it, and the example policies in my GitHub at https://github.com/vwal/awscli-mfa