When you are logged in to the AWS web console, users, groups, and roles can be created by navigating to the IAM service page:

1. To get to the IAM page, click on the Services button on the top-left of the page, then search for and click on the relevant link to the IAM page:

2. The following figure shows the relevant links for users, groups, and roles on the IAM dashboard. Click on Users to continue:

3. To create an IAM user, click on the Add user button at the top-left of the page:

You will then be presented with a page that requests a User name and the type of access to provide to the new user. One of the two types of access that you can choose is Programmatic access, which creates an access key ID and secret access key for the user, so that they can access the AWS APIs through something like the AWS CLI or the SDKs provided for various programming languages. The other is AWS Management Console access, which will either autogenerate a password or allow you to set a custom one, so that the user can access the AWS web console.

4. For our example, let's create a user named Test that is allowed programmatic access to the AWS APIs. Once that has been filled out, you can click on Next: Permissions to continue:

5. After continuing, you will be presented with three options to set up permissions for this new user.

The three options that are presented allow you to do the following:

• • Add the user to an IAM group
  • Copy the permissions of another existing user
  • Attach the existing IAM policies directly to the user

Click on the third option to attach an existing policy directly to the user:

After doing so, you will be presented with a list of IAM policies.

6. In the search box that appears, type in AmazonEC2FullAccess and check the box to the left of the policy that appears. This policy will provide the user with full access to the EC2 service, as well as other services that are often used in tandem with EC2. If you are interested in viewing the JSON document for this policy, you can click on the arrow next to the policy name and then click on the {} JSON button:

IAM policies are documents in JSON formats that specify what permissions are allowed or denied, what resources those permissions apply to, and under what conditions those permissions are valid for a certain user, group, or role.

There are two kinds of IAM policies: policies that are AWS managed and policies that are customer managed. An AWS managed policy is a pre-defined set of permissions that AWS manages. AWS managed policies can be recognized by the small orange AWS symbol next to the policy name. Customers are not allowed to modify these AWS managed policies, and they are provided as a method of convenience when setting up permissions:

Customer managed policies are the same as AWS managed policies, except that they must be created, and they are fully customizable at any time. These policies allow you to delegate fine-grained access to the various IAM users, groups, and roles in your account.

7. We can now click the Next: Review button towards the bottom-right of the window to move on. The next page will be a summary of what we have just set up, so we can go ahead and click on the Create user button towards the bottom-right of the window.
8. Next, you should be presented with a green Success message and the option to either view or download the associated Access key ID and Secret access key for this new user:

The same general process can be followed to create roles and groups, as well.

If we want to create a group and add our new user to it, we can follow these steps:

1. Navigate to the Groups tab of the IAM page in the AWS web console, then click on Create New Group in the top-left corner.
2. Supply a name for this group; in our example, it will be Developers.
3. We will be asked to select an IAM policy to attach to this group, which we are going to search for; we will add the IAMReadOnlyAccess AWS managed policy to our group.
4. Hit Next Step, and we will be presented with a summary of the group that we want to create, where we can complete the process by clicking on Create Group in the bottom-right, as shown in the following screenshot:

5. Now that the group is created, we can click on it from the IAM groups page, and we will see something like the following screenshot, where we can click on the Add Users to Group button to add our new user to it:

6. We can then search for and check the box next to our previously created Test user, and then click on the Add Users button, as shown in the following screenshot, to complete the process:

7. Now, if we navigate to the user page for our Test user, we can see that we have our previously attached AmazonEC2FullAccess AWS managed policy attached to our user, as well as another section, Attached from group, that includes the IAMReadOnlyAccess AWS managed policy that our user has inherited from the Developers group:

8. If we are curious about what groups our user is in and what policies our user is inheriting from them, we can click, the Groups (1) tab, and it will give us that information:

Roles cannot be added to groups, but IAM policies can be attached and removed from them in the same way that they can for users and groups. Roles have an additional important feature known as trust relationships. Trust relationships specify who can assume (request temporary credentials for) the role in question, and under what conditions that can occur.

I have created a role that has a trust relationship created with the AWS EC2 service, which means that EC2 resources can request temporary credentials for this role. The following screenshot shows the Trust relationships tab when viewing a specific role:

In the highlighted section, we can see that we have one trusted entity, and it is The identity provider(s) ec2.amazonaws.com.

Trust relationships are specified in a JSON document known as the assume role policy document. Our example role has the following assume role policy document specified:

{
  "Version": "2012-10-17",
  "Statement": [
    {
     "Effect": "Allow",
      "Principal": {
        "Service": "ec2.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

Policies and their supported keys will be described in more depth in the next section, but basically, what this JSON document says is that the EC2 service (the principal) is allowed (the effect) to run the sts:AssumeRole action while targeting this role. Principals can also include IAM users, other AWS services, or other AWS accounts. This means that you can assume cross-account roles, which is a common way to establish persistence in an account as an attacker. This will be described further in Chapter 11, Using Boto3 and Pacu to Maintain AWS Persistence. We will now continue by looking at limiting API actions and accessible resources with IAM policies.