AWS Identity and Access Management, or IAM, is a critical AWS component controlling access to your AWS resources. The IAM user and the IAM role are two crucial IAM concepts with similar features. So, sometimes, it can be difficult to tell the difference between them. In this post, we will discuss the similarities between AWS IAM users and IAM roles and how they differ.
As you probably know, a root user account is created when you first sign up to AWS with your e-mail address. The root user has full access to do anything on AWS, and using it for your everyday tasks is a security risk, even if you enable MFA. Therefore, using a root user account only to create an IAM user with administrative permissions is an AWS security best practice. Then, with this admin user, you must create other IAM users and roles for your employees or colleagues and assign them the necessary permissions to perform the regular tasks.
What is an IAM User?
But how do the IAM users and IAM roles work exactly? Let’s first begin with the IAM user concept. IAM users are identities you can create on AWS to access AWS resources. Even to perform one of the basic actions on AWS, such as creating an S3 bucket, an IAM user must have explicit permissions. Otherwise, it will automatically get an ‘Access denied’ error.
By default, IAM users don’t have any permissions at the start, and all actions are denied at first. You grant permissions to them with IAM permission policies in the form of JSON documents. In all cases, associated permission policies determine what an IAM user can and cannot do on AWS.
Unique credentials for better security
Each IAM user has an account-level unique name and credentials. For the optimum level of security, AWS recommends creating separate IAM user accounts for each person who needs access to AWS instead of building one user account for multiple users. Also, to efficiently manage the permissions of your users with the same level of responsibilities, you can group them under an IAM user group (a development group, admin group, etc.) and attach a permission policy to that group. So, each user in the group will have the associated permissions.
IAM users can access AWS resources with two types of credentials: usernames/passwords and access keys. In your IAM user account, you must log in to the console with your username and password to use an AWS resource through the AWS Management Console. Alternatively, to run an AWS CLI (Command Line Interface) command or call AWS APIs or SDKs (Software Development Kit), you use access keys and secret access keys to validate who you are and whether you have permission to perform that action.
How an IAM Role is different from an IAM User?
Until now, we only talked about the IAM user concept. Now, let’s discuss the features of the AWS IAM role.
Like IAM users, IAM roles are identities you create on AWS to gain access to your AWS resources. However, unlike IAM users, IAM roles don’t have long-term credentials such as a username and password. Instead, when you assume an IAM role, you get temporary permissions and short-term credentials for your role session. After this session expires, you cannot reaccess it using the same credentials. So, you ensure to update your credentials in short intervals when using roles.
IAM roles are similar to IAM users regarding permission policies that allow or deny actions. However, they are not specific to one person and can be delegated and assumed by anyone who needs them, such as users, applications, etc.
Services can also assume IAM roles to run actions on your behalf. You can use a service-linked IAM role directly linked to and predefined by specific AWS services. Service-linked roles contain all the permissions necessary to act on your behalf.
Examples of Using IAM Roles
Granting Temporary Access to People
To explain the IAM role better, let me give a quick example. Suppose you need to intervene in an urgent Lambda project and need temporary access. After granting necessary permissions, you can assume the related role by switching roles in the AWS Management Console or, in another way, using the AWS STS service by calling its API endpoint. Then, you can get temporary credentials for it and act like that role you need for your project. Remember that when an identity assumes an IAM role, it abandons all previous permissions and can only assume the new role’s permissions.
IAM roles are flexible and ideal for quick and short-term needs. They can be used in a variety of cases. For instance, a user in another AWS account may need to access the resources in your account. Or, in another case, you may want to grant access to specific AWS services for some users outside AWS. In these situations, users can access the required AWS services immediately by assuming necessary roles for their projects.
Granting Temporary Access to Software Applications
Another example is getting temporary credentials for your application. I saw many AWS users embedding long-term IAM user credentials to the environment variables of their Amazon EC2 instances, Lambda functions, or, even worse, to their codebase. However, creating an IAM role and attaching it to the EC2 instance, AWS Lambda function, or an ECS task, wherever you deploy your app, and using the AWS SDKs provided for your programming languages would be a more secure way to access AWS services.
Suppose your application users need separate temporary credentials. In that case, you can use Amazon Security Token Service (STS) to provide temporary credentials to your app users by enabling them to assume an IAM role instead of using the app’s general credentials. In this way, you can also differentiate user privileges according to their roles in your application. For example, an application manager can assume more privileges than a junior developer, etc.
Using IAM Roles is an AWS Security Best Practice
Having discussed the basics of the IAM user and the IAM role, let’s finish our article with an AWS security best practice. Of course, which IAM component (IAM user or IAM role) you should use varies depending on your use case. However, AWS recommends using IAM roles with temporary credentials where possible instead of IAM users with long-term credentials or access keys. Most AWS users forget to renew their IAM user passwords or programmatic access keys regularly.
Especially when you need to grant a mobile device or any third-party account access to your AWS resources, arranging temporary access would be more secure than using long-term credentials. Besides, please avoid hardcoding your credentials in your codebase or environment variables. Use IAM roles wherever possible.
Conclusion
IAM user and IAM role are two crucial AWS concepts that securely manage access to the AWS resources. This post summarizes the features of IAM users and IAM roles with their differences.
IAM roles provide short-term credentials and can be assumed and used by multiple principals: a user, a service, or an app. On the other hand, an IAM user is unique to one identity, and it requires long-term credentials to perform AWS actions, like passwords and access keys.
Using IAM roles wherever possible is an AWS security best practice as they enable you to use temporary credentials instead of long-term passwords or access keys. If a malicious attacker gets your IAM role’s temporary credentials, they will mostly be expired or have a short-term usage window remaining. In contrast, long-term credentials with IAM users will give the attacker more chances to exploit.
I hope this post helps clarify the differences between AWS IAM users and roles. Thanks for reading, and see you in my other posts!
References
- IAM Identities (users, user groups, and roles) - AWS Reference
- AWS Identity and Access Management Best Practices
