Deep Dive into AWS IAM

Identity and Access Management is an AWS service that you can use to manage authentication and authorization in your AWS account.

Authentication: Who can log in to the AWS account

Authorization: What actions user can perform on AWS resources

It is essential to use IAM to make sure the users only have the permissions required to do their tasks. For example, we do not want our EC2 Administrator to mistakenly modify our VPC firewall rule as this can put the machine’s security at risk. In this post, we will perform tasks to understand how IAM works.

Task – 1: Let’s secure our Root Account

When we create an AWS account, we get a single identity to login into the AWS account using an email address and password that we used to create an AWS account. It is known as the root user, and this user has access to all the resources on our AWS account.

AWS recommends not using the root account for our day-to-day tasks. However, use the AWS root account to create IAM admin and only use the root account when required. Let’s go ahead and first secure our root account.

We login into our AWS account using the root user and opened the IAM service tab to see what we could do. In the IAM dashboard, we can see security recommendations from AWS for the root user.

The first suggestion is to add MFA (Multi-Factor Authentication) for my root user. This is an extra security check to make our root account secure. Let’s go ahead and click on add MFA.

AWS console takes us to a different window where it asks us to activate MFA and request to select the MFA device that we will use.

I don’t have any hardware device, so I will select Virtual MFA. I will install Google Authenticator on my mobile device for this virtual MFA.

Once I clicked continue, AWS asked me to perform several steps to configure MFA for my root account using my authenticator app.

I performed these steps and assigned MFA to my root account. Now, I can see the first task is marked completed on the IAM dashboard.

If I log in again into AWS UI, I will be required to provide the code from Google authenticator after providing my email and password. This adds an extra layer of security to my root account.

Our second recommendation is to deactivate or delete the root user access key. Access keys are used for programmatic access. We can invoke an action on AWS resources from our application or third-party tools such as Terraform with these access keys. As it is root user access keys, it will provide complete access to AWS resources, so AWS does not recommend using root access keys for daily tasks. Due to this, we can see a recommendation to deactivate or delete the root keys. Let’s go ahead and deactivate these root access user keys.

When we click Manage Access Key on the IAM console, it takes us to a different page to see root user keys with more detailed information.

As per AWS recommendation, I deleted the root access keys from UI in my account, as I don’t require these access keys.

On the AWS IAM Dashboard, now we can see we do not have further recommendations.

Task – 2: Let’s Create Admin user for the AWS account

We will not use the root user for our delay tasks, but we require a user to perform different admin operations in our account so let’s go ahead and create an admin user. We can create an admin user with all required permissions, but it’s not good practice if we need multiple admins in our account.

In my environment, I will first create an admin group with the AdministratorAccess policy(Policy is s list of permissions, but we will discuss this more incoming tasks) that provide admin access to the AWS account. If I add users to this group, they get all the permission as per the policy attached to the group. We are creating a group because if I need to create a new admin into my account, I will just add that user into this group rather than assigning permissions individually.

Creation of Group:
On the IAM dashboard, we can see a section for User groups to create a new group and see existing groups.

I will click “create group” on AWS UI to create a new admin group. To create a new group, we need to provide information related to the group.

1. Group name: awsadmin

2. Add users to the group: I currently don’t have any to add to this group, so I will leave this section.

3. Attach permissions policies: I will attach the AdministratorAccess policy to my group and click create a group.

In the User groups tab, we have a new group with the awsadmin name, and any user added to this group will get admin access as per the attached policy.

You can click on the group name to get the details about the group, such as users and permissions.

Creation of user:

On the IAM dashboard, we can see a section for users to create a new user and see the existing users.

I will click “Add Users” to create a new IAM user that will act as admin for my AWS account. To create users, we have to provide information related to the user.

1. In the first section, we need to provide a Username and access type. I have selected “AWS console access” to allow login from UI for access type. I will generate Access keys in the future if required for this user.

2. In the second section, we need to set permissions. I have selected the “awsadmin” group we created in our first task.

3. I will leave the rest as default and create a user with the provided information.

Once you create a user, you will get a sign-in URL on AWS UI that you need to use to login into your AWS account as an IAM user. Please find the login example using an IAM user.

Now we need to create new groups and users for different teams. For example, development team users need access to the S3 bucket and EC2 machine, and we cannot create new users add them to the awsadmin group because that will provide access to all resources. As this task involves working with policies and Programmatic access, we will first understand IAM policies and Programmatic access.

IAM Policies

We create an IAM policy and attach it to IAM identity or resources to define permissions on the AWS side. IAM policies let us define what action users, groups, and roles can perform on AWS resources. We can also assign policies to resources to control access, such as S3. IAM policies use JSON syntax and any JSON policy can have the following information:

Version: To specify the Policy Language version. The latest is 2012-10-17.
Statement: It holds information about single permission and your policy can have multiple statements.
Sid: Optional statement ID to differentiate between statements and to give info about the permission.
Effect: To allow or deny access to resources.
Principal: It’s used in resource-based policy and it will be generally the IAM identity to which you are providing access to resources.
Action: List of actions, you want to allow or deny.
Resources: To specify the resources on which action will be allowed.
Condition: It’s optional and it’s the kind of condition that needs to meet for action to be performed.

AWS supports six types of policies:

1. Identity-based
2. Resource-based
3. Permissions boundaries
4. Organizations SCPs
5. ACLs
6. Session policies

In this blog, we will talk in detail about identity-based and resource-based policies because these are the ones we will use to perform tasks. Other policy types are also important and provide more advanced security options.

Identity-based Policies

Identity-based policies are attached to IAM identities such as user, group, and role to define their permission. For example, I can create a policy that provides full access to EC2 resources and can attach to a user X. Now user X can perform all the actions on EC2 resources but not any other resources.

When we require to set the policies for Identity we have to choose between three options as per our needs:

1. AWS Managed Policies
2. Customer Managed Policies
3. Inline Policies

AWS Managed Policies:

These are policies created and administered by AWS. These policies are designed for many use cases, such as we used the AdministratorAccess policy to create a group with admin permission to perform daily tasks. As AWS manages these, we cannot change permissions inside the policy.

These policies are here to make our life easy as these policies are designed for common use cases, so we do not have to write and update policies based on changes on the AWS side. A straightforward example, we write a policy to provide read-only access to all services by listing them. If AWS adds more services into their catalog, we must update the policy based on new services. If we use any AWS-managed policy, AWS will automatically update the policies permissions based on new resources.

On AWS UI, you can identify if the policy is AWS-managed or customer-managed. Please find the screenshot below for an example:

To view the information about the policy permissions, you can click on the + icon for a detailed view in JSON or you can read the description to get the basic idea.

Customer Managed Policies

When Managed policies cannot be used for our use case, we can create a new policy as per our need. These policies will be knowns as customer-managed policies. When we click to create a policy, we get three options:

1. Visual Editor: We can use UI to create policies without worrying about JSON Syntax.

2. JSON: We can write our policy using this JSON editor. We can also paste any existing policy and edit it here to make a new policy for our use case.

3. Import Managed Policy: On the Top right, we can see the option Import Managed policy. It is the easiest way to create a new policy. We can import any existing Managed policy that holds some permissions we require and edit in Visual editor or JSON editor as per our need.

Inline Policy:

Inline policies are embedded into the IAM identity and cannot be reused. Use inline policy when managing permissions for a specific user as these cannot be reused. For example, user EC2-admin is a part of a group that provides full access to EC2 resources, but we do not want the user to access the EC2 resources in the us-east-1 region. If we modify the group permissions, all group users’ permission will be affected. To avoid this, we can create an inline policy for user EC2-admin that blocks access to EC2 resources in us-east-1. Now user EC2-admin will get full access to EC2 resources in regions due to group policy except us-east-1 due to inline policy.

Please be aware that inline policies are not visible in the policy tab, we can only see them while reviewing the permission for IAM identity. Please find the example for EC2-admin user permission.

<—————————In Progress—————————–>