A foolproof guide to AWS IAM Roles

Introduction¶

The FaceLess Men in GoT (Games of Thrones), hope you remember this character, or Raven/Mystique in X-Men. They both share a common power, what would that be?

The power to change identity as they wish to accomplish the task at hand. This is what IAM Roles do in a very broad sense.

You can also think of IAM roles as the Invisibility Cloak in Harry Potter, who ever acquires it becomes invisible.

IAM Roles are just like a hat, which anyone within AWS can wear, and get the powers presented by the hat, and loses the powers as soon as the hat is removed. The hat does not discriminate between real users or hardware like EC2, anyone can wear this hat.

You will also see how IAM Roles can be used, how it is created and attached. You will also see how IAM user is a different concept than IAM Role.

IAM Roles¶

An IAM role is an identity that you can create having very specific permissions. The only difference being you are not associating this policy to any particular user or services at the time of creation. This IAM role can be assumed by anyone who needs it, be it a user or an AWS resource.

You might be thinking, which problem does IAM role solve which a normal IAM user or a new IAM policy cannot solve. So lets understand why we need the use of IAM Role.

IAM Roles for user¶

When you are creating a user in your own account, you cannot give them all the permission as explained in IAM Introduction, the principle of least privileges. You cannot have one or multiple users will super user permissions, you cannot have Batman in every city, only Gotham.

In addition, we can also have non AWS accounts, like cross account want to access your AWS services, or the federated user, who may also need access to the AWS services in case of Hybrid Cloud.

You have to consider many other use-case along with the above two, for understanding we cannot keep on creating IAM Users to address such diverse range of permission request.

IAM Roles for AWS Services¶

You might have already read about IAM Policy, AWS resources cannot have IAM policy attach directly. There is another good policy, AWS credentials should not be stored on EC2 instances.

If you consider the above two guidelines, it will not be possible for any AWS services to communicate with other AWS services / resources to complete the work.

IAM Roles to the rescue¶

When you consider both the limitation of IAM User and AWS services, you can think we need some type of magic hat, which gives the sufficient power to both User or Service to execute the task it is elevated for. This is where magic happens with IAM Roles.

You can use IAM Roles for:-

• One AWS service have to access another AWS service.
  • Example: Application running on EC2 may need to access S3.
• When you have a Hybrid Cloud implementation
  • User from On Premise may want to access AWS Cloud infrastructure.

EC2 can assume a role only at the time of creation, but once it has a role attached, you can modify it using APIs, CLIs or console at any time. You can attach only 1 role to EC2 at any given time.

Benefits of IAM Role¶

• You may need people from Hybrid cloud implementation to access the AWS account, you may need IAM Roles to be attached once these users are authorized to use SAML or Active directory.
• You may have production and development account in AWS, and your development team may be required to be elevated to access a production account to fix a bug. This can be done using IAM Roles.
• You have an application running on an EC2 instance, It needs access to S3, this can be achieved using IAM Role.

How to create an AWS IAM Role¶

AWS IAM Role creation is a three step process.

Step 1 | Select the trusted entity¶

The first step guides you choose which services or identities can assume the role, your options are

• AWS Services
  • The EC2 instance, lambda etc which needs access to other services.
• Another AWS account
  • This is a cross account access, like a developer taking a production access etc.
• Web Identity
  • Using OIDC to validate user, like the mobile phone apps.
• SAML 2.0 Federation
  • Using office resources as authentication parameters, like using service Active Directory.

You can select AWS Services for this experimentation, You can attach this to an EC2 instance, so that it can access the S3.

Step 2 | Attach permission policy¶

You can now select policy required to be attached, this step is same as the explained in IAM Policy. You have basically chosen from one of these 2 type

• Custom policy, created using the visual editor or JSON editor.
• AWS managed Policy.

You can select the AmazonS3ReadOnlyAccess for attaching to EC2 instance as agreed in Step 1.

Step 3 | Review¶

You have to provide these details to complete the IAM Role Creation process.

• Role Name
  • An explicit name, which can be used to attached to the EC2 instance.
• Role description
  • A description about the role.
• Trusted Entities
  • This is the service selected from Step 1.
• Policies
  • The policies attached, in this case AmazonS3ReadOnlyAccess

How does the IAM roles looks after creation?¶

You can see above, this is how an IAM Role looks like after creation. The policy document looks exactly same as an IAM Policy. This you can also assume as a baton in a relay race, the service or the user can run with the permission as soon as it gets the policy in the form of an IAM Role.

IAM Roles Vs IAM Users¶

You should see this video tutorial on YouTube. This video explains much better, also the flow chart shown above should also clear your doubts

You can see the logic is elementary,

• If you have a non living things, like EC2 etc., it gets an IAM Roles. No question asked.
• If it is a living thing, like a person, we have to ask two questions.
  • If the permission is temporary then he gets an IAM Roles, else he is an IAM User.

Hope this clears your mind about the difference between two confusing terms.

IAM Roles Vs IAM Policy¶

IAM Roles and IAM Policy both have a JSON document identifying the rule. The only difference is the mention of Trusted Entities.

Conclusion¶

You might now be relieved by understanding the concept of IAM roles, as discussed we use IAM Roles for mainly three purposes.

• One AWS service using another service, like EC2 instance, wants to read from S3.
• In the hybrid environment, a non AWS user might need access to AWS resources temporarily.
• Cross account access, where a developer may need access to production account.

You should also think of an IAM Roles as a hat, which a person or services wears and it magically gets the permission and when it drops the hat, it comes back to original state.

You also should think about EC2 instance, it should not store the IAM User credentials, they should be using the IAM Roles instead. The IAM Roles can be attached to an EC2 instance, during creation, and can be changed afterwards, but not attached after creation. You can attach only one IAM role to an EC2 instance and not multiple.

You learned that IAM Role creation is a 3 step process.

• Select the trusted entity
• Attach permission policy
• Review

The IAM Role has been just like IAM Policy document, a JSON document having statements.

You can be confused with IAM Role and IAM User, we can simplify it, saying, if it is a resource we use an IAM Roles. If a physical user needs temporary access, it uses IAM Roles, otherwise it is an IAM User.

You can comment and let me know if the IAM user is different than IAM Role.

Reference¶

• Photo by Ales Nesetril on Unsplash
• Photo by Laura Thonne on Unsplash
• Photo by Ali Kokab on Unsplash
• Photo by Almos Bechtold on Unsplash
• AWS IAM Overview - It’s Surprisingly Simple - Users vs Roles