We are going to be talking about AWS Identity and Access Management (IAM) beginning with this post. If you have read through the previous two AWS posts then you should have already set up a labuser account and admin group.

Please login to your AWS account and navigate to the IAM service by typing iam in the search box and then clicking IAM in the search results.

The IAM user is an item that we create in AWS to represent either a person or application. It will be used to access our AWS environment. Users will be composed of a username and credentials (i.e., password).

We will have two types of users to think about when working with AWS – the root user and regular IAM users.

The root user is created when a new AWS account is created. It is access with the email address and password used to create our account. By default it will have full access to our accounts and should never be used for everyday tasks. We will set up a regular IAM user to conduct our administrative activities.

In our previous two posts we secured the root user in our accounts by completing each of the tasks shown in the Security Status list in the IAM Dashboard. You should see a green checkmark next to each of the items but if you do not then please visit our previous two posts.

Please click on the Users link on the left side of your screen to view the regular IAM users that have been set up.

I am using a new account for this blog series and the only IAM user listed is the labuser account which we set up in our two part posting on securing the root user.

A new IAM user will have an associated implicit deny for all AWS services when it is created. It will represent a person or service that will use the account to interact with AWS.

User accounts in AWS will consist of a name, a password that will be used to sign into the AWS management console, and up to two access keys that will be used with the AWS API or CLI. We will discuss the API and CLI in separate blog posts.

AWS users are assigned unique credentials that could be either a password or access keys depending on how the account will interact with our AWS environment. Passwords are used to access the Management Console and access keys to make programmatic calls to AWS API operations or for accessing the AWS CLI.

IAM policies can be directly applied to an IAM user or they can be attached to an IAM group. An explicit deny will always override an explicit allow in an IAM policy. For instance, if a single deny all is added to a policy then all allow statements will be ignored. We will go deeper into policy creation in a later post.

There are some best practices that we will need to keep in mind when working with IAM users:

• We should never store or pass our access credentials to an EC2 instance. SSH forwarding should be used instead.
• Multi-factor authentication should be used for each IAM user account.
• Access credentials should be unique for each user and never shared.

Click on Add user and we will walk through the process of creating a new user.

I am going to use testuser1 as my User name. We have two different access types to choose. Programmatic access grants access from the AWS API, CLI, or various SDKs and development tools. AWS Management Console access grants access to the Management Console.

Programmatic access and AWS Management Console access will both be granted for this demonstration. We do this by checking the boxes as shown in the above screenshot. It is considered best practice to only create the minimum credentials that will be needed by the account. Set a Custom password and uncheck the box requiring password reset since this account will be for demonstration purposes only. Click Next: Permissions.

The next screen will be where we Set permissions for our new user account. We can Add user to group, Copy permissions from existing user, or Attach existing policies directly.

• Add user to group: We would choose this option if our goal was to assign users to one or more groups that have been assigned IAM policies.
• Copy permissions from existing user: We would choose this option if our goal was to copy all of the group memberships, attached managed policies, embedded inline policies, and any permission boundaries from an existing IAM user to our new account.
• Attach existing policies to user directly: A listing of AWS and customer managed policies would be generated if we choose this option. We could either select an existing policy or choose Create policy to build a new one.

We are not going to select any of these three options since this is a demonstration so go ahead and click the Next: Tags button at the bottom right hand corner of your screen.

Tags allow us to add metadata to our IAM users in the form of key-value pairs (i.e., tag key location could be paired with tag value us_va_norfolk). We are building this account for demonstration purposes and will not choose a tag. Please click the Next: Review button.

There will be a warning in the review screen because we have not assigned any permissions.

The account will have an implicit deny for all AWS services because we have not assigned permissions. Go ahead and click the Create user button.

The new user will have an Access key ID and Secret access key assigned that can be used to configure the AWS CLI to allow our testuser1 programmatic access to our AWS environment. This will be the only opportunity to access these keys so click the Download.csv button and store the file in a safe location.

We click Close and are returned to the IAM User list.

The testuser1 account has not been access to any service so we will add a policy to make the account an administrator. Click on the user and then click the Add permissions button.

Select Attach existing policies directly and you will see a list of policies that will be classified as AWS managed or Customer managed policies. We will be discussing policies in much more depth in another post so for right now select the first policy, AdministratorAccess.

Click the Next:Review button at the bottom right corner of your screen and then click the Add permissions button.

We have created an IAM user and assigned permissions to it and will finish this post by taking a quick look at IAM Groups. These are used to assign permissions to a block of IAM users. Click on the Groups link to view the groups that are already in your account.

The lab account was built for this blog series and only has one group – admin which we created during the two blog posts on securing the AWS root user account.

Click the Create New Group button.

We will call our new group lab admin.

Click the Next Step button at the bottom right hand corner of your screen. Attach the AdministratorAccess policy by clicking the checkbox next to the policy name.

Click the Next Step button at the bottom right hand corner of your screen and then the Create Group button. The labadmin account will now be listed in our IAM group list.

There are no users assigned to the group so click on it and then click the Add Users to Group button.

The next screen will present us with a list of users. Check the box next to testuser1 then click Add Users. This will add the user to our labadmin group.

The labadmin account will now have the testuser1 account attached to it.

The account is now a member of the group. It will have almost all of the permissions of the root user with the exception of billing permissions. Select the Permissions tab and the Attach Policy to add the billing permissions to our group.

Type billing to locate the Billing policy and the check the box next to it and then click the Attach Policy button at the bottom right hand corner of your screen.

The labadmin now had the Billing and AdministratorAccess policies attached.

The testuser1 account is a member of this group so we can remove the AdministrativeAccess permissions that were previously assigned. We do this by clicking the x next to the policy in the account screen.

Click Detach in the pop up box to confirm that you are detaching the AdministrativeAccess policy.

You will now see the two policies attached to testuser1 by the admin group.

Groups allow for assignment of policies to multiple users at the same time. Permissions can be assigned at the group level which streamlines the assignment process. One thing that we need to be aware of is that AWS Groups are not hierarchical. They cannot be nested. In other words, we cannot create a group inside another group but a user can be a member of multiple groups.

Some best practices for groups:

• Organize them by function (i.e., database administrator, architect, etc.)
• Assign IAM policies to groups verses users.

In this post we discussed IAM users and groups. We will discuss policies in more detail in our next post.

Thank you for taking the time to visit cloudsecurityessentials.org. If these posts are beneficial to you then we ask that you consider sharing them with your friends and colleagues.

We recommend AWS: The Complete Beginner’s Guide to Mastering Amazon Web Services by Stephen Baron (https://amzn.to/2Lz5eBF) as a supplemental resource for this blog series. You do not need to purchase this book in order to “credit” our account. Any purchases that you search or make from anywhere in Amazon after clicking on the provided link, will credit this blog and support the continued growth of the library. We are truly grateful for each of our readers and appreciative of those who will help us. There is no cost to you for using our links and they provide an easy way for you to support us.