An Overview of AWS IAM Roles and Policies

In this article, I am going to introduce the concept of AWS IAM, also known as Identity and Access Management in AWS. In any cloud service, controlling who has access to the services and how each of the services accesses the other services is an important task. If we do not control the access or restrict then there might be cases of a security breach within the services and we might not be able to track those as well. So as a best practice to restrict or control access within the AWS, there is a special service called IAM that can be used to manage and control almost everything in AWS. It is the permission control system that controls access to the various AWS resources and services.

In order to follow along with this article, it is best suited that you have an AWS subscription which can be used to verify and understand the topics that we will use in this article.

Understanding AWS IAM components

Identity and Access Management (IAM) is a service offered by Amazon to control the users, create groups and allow or deny access to specific resources within the AWS environment. You can use this service by logging into the AWS Management Console and search for IAM.

The AWS IAM service will be opened and you can see the following. There are four major components of the IAM service.

• Users
• Groups
• Roles
• Policies

Let us now understand each of the components in detail.

Users

As per the definition from the official documentation, “An AWS Identity and Access Management (IAM) user is an entity that you create in AWS to represent the person or application that uses it to interact with AWS.”. Basically, you will have to create a user for each and every individual that you would want to access your AWS Account. There is also a possibility to create delegated users for your application, but that is out of scope for this article.

There are two types of users in the AWS Management Console – Root User and IAM User.

The Root user is the first user that is created when you create an AWS Account for the first time. It has access to every possible resource within the AWS Account. As a best practice, it is advised that you should not be using the root user for your daily activities, instead create an IAM user and use it for your development. The root user should only be used to perform specific activities such as billing etc.

The AWS IAM user is one that you create using your root user and can be used to login to the console later. Once the IAM user is created, you should start using it for your daily activities and leave the root user account secured.

Groups

As you might have guessed, in AWS IAM, the groups are a collection of IAM users. Using groups you can get rid of assigning a specific set of permissions to each individual user. Instead, you can assign specific permissions to a group and then add IAM users to that group. All the users in a group will have similar access.

For example, you can consider creating different groups for various teams within your organization like Admins, Developers, Testers, etc. You can then assign specific permissions to these groups. Whenever a new user is onboarded, you can assign the user to a group, and then the user will have all the permissions assigned to that group. You can add the same user to multiple groups. By default, when you create your AWS account, there are no groups created. You need to create groups on your own according to your requirements.

Policies

So far, we have learned about IAM users and groups in AWS, but we did not understand how to allow or deny access to the users or groups. This is specifically done using policies. Policies in IAM are objects that can be assigned to users or groups and control their access to the resources on AWS. Whenever a user requests a specific resource, these policies are evaluated while the request is made. If the policy allows access, then the user or the group will be able to access the specific resource as requested.

There are quite a few types of IAM policies of which the following two are the most important ones.

Identity-based policies – These policies are attached to IAM users or IAM roles (we will see them later in the article). It defines to which resources the IAM user has been granted or rejected access toResource-based policies – These policies are attached to specific resources on AWS to define how they can interact with other resources within the AWS environment. These are used to define delegated permissions for resources like EC2 to have access to an S3 bucket within the same AWS account

A policy in AWS is defined using JSON and looks something like the below.

As you can see in the figure above, the JSON statement defines the administrator policy in the AWS account. There are a few components of the policy JSON statement like version, an array of statements, and each of the statements can have an effect, action, and a resource specified.

Version – It is used to specify the version of the policy language. For most of the cases, you will be using the default and latest version 2012-10-07Statement – Used to define the policy for a specific element. A policy can have one or more statementsEffect – Defines whether you want to allow or deny accessAction – Defines from a list of actions that can be performed on a resourceResource – The IAM ARN of the resource on which the permission is being granted

You can read more about policies in detail from the official documentation. You can also customize your policies to allow more restricted access. For example, you can also define policies that allow access to resources only during specific hours of the day or only while using a Multi-Factor Authentication. These are complex topics and beyond the scope of this article.

Roles

IAM Roles are an important concept in AWS. You can think of roles as permissions, not for a user, instead of for an AWS service itself. In the previous sections of the article, we have seen what IAM users are and how to allow access to these users to specific resources in AWS. However, when an AWS resource needs to access contents within the AWS, then we cannot create a user for the user. In such cases, we create roles with policies and then allow the AWS resource to assume the role while making the requests.

You can consider a scenario where an EC2 instance might want to read data from an S3 bucket. Here, we can create a role that has FullS3Access and then allow the EC2 instance to assume the role.

Conclusion

In this article, we have understood the concept of AWS IAM. It is one of the most important services that need to be correctly set up for any organization before the development and other activities are initiated. There are also a few best practices suggested by Amazon that should be followed while designing the IAM structures. As already mentioned in the article, there are two ways of accessing resources on AWS, either by a username and password or by using secret access keys. You should also keep an active eye on and monitor the activities within your AWS Account. You can read more about monitoring activities from the official documentation.