Users

Every IAM user receives Amazon Resource Name (ARN). It is similar to object id in Active Directory and is of the format:

arn:aws:iam::<account-id>:root
arn:aws:iam::<account-id>:user/iam-username

More details about ARN are already explained here.

Console Access

When logging into AWS, using root account, one can simply navigate to https://console.aws.amazon.com, which will redirect to domain signin.aws.amazon.com

However, when logging using IAM account, one can simply use the 2nd option as mentioned in the above screenshot and simply provide the options as mentioned in the below screenshot:

Now one can either provide account ID (which is 12 digit numerical id) created when one sign-up for AWS or simply provide an account alias (as its difficult to remember the 12 digit number) in place of account id to access further and lastly provide the IAM user and password to login, provided the IAM user has console access.

Now, one can understand the steps can be referred to see how to create an IAM user and provide the user console access in IAM console. If its the first IAM user, then one has to use root account privileges. To be specific, the following account that is created is the administrator account which can be used to manage day to day operations in AWS.

Instead of creating user with administrator access individually, a group has been created with administrator privileges as shown here.

Every IAM user access resources based on assigned permissions.

Note, one can also access AWS console via https://<account-id>.signin.aws.amazon.com for AWS IAM Users to login

Forgot Password

As said above, IAM users would have to go to their IAM administrators for password reset. This is particularly useful to prevent SSPR (Self Service Password Reset) abuse in phishing attacks.

Programmatic Access

Next, one can also create access keys to let the user access AWS programmatically or using cli. It is like user-id (Access Key ID) and password (Secret Access Key) for programmatic access.

Moreover, the best practices for them are as follows:

Rotate access keys every 90 days
Store access keys in secure manner

Note: Refer here on how to use access keys and MFA to create short term credentials for best practices. This is particularly useful to avert the risk of long term damage in case the user's system is compromised.

Note, if the access key is for an application, then one can create a different user with only cli access that has access to particular resource in AWS, store it in AWS secrets manager and then give EC2 IAM instance profile to fetch only that particular AWS key from AWS secrets manager as security best practice

Delete unused keys
Monitor usage of access keys

It can be created as shown below:

Note: If the primary use case of access keys is going to be to use it to perform operations across AWS service to do repetitive tasks or save time to do something over cli for better productivity, then CloudShell can also be used as shown below. It is simply better because there is no requirement to ever store access keys locally in user's system in this case.

Note that Access Key ID starts with AKIA for long term credentials and ASIA for short term credentials

Password Policy

It is basically used to configure the following:

Character requirement like small alphabets, capital alphabets etc.
Minimum Password Length.
Validity of the password in terms of its expiration.
Number of times it is allowed to do attempt entering password for users.
Reusability of Passwords

Password Policy can be managed as shown below:

Setting up MFA

This is used to setup extra layer of security.

For demo, lets configure using Software based Authenticator app. OneAuth, Microsoft Authenticator, Google Authenticator, Orange Authenticator etc are supported. We can also configure using browser extension from authenticator.cc