Popular with:
Cloud Engineer
Security Engineer
Cloud Security

AWS Security Basics: IAM Users vs. Roles vs. Groups

February 15, 2023
Written by
Aneesh Bhargav

AWS security can get really complicated, really fast. If you're a newbie to developing on AWS or still learning cloud security, the best place to start is by understanding the basics of AWS Identity and Access Management (IAM).

In this article, we're talking about IAM identities. Specifically, we'll be looking at users, roles, and groups in AWS IAM, how each of them work, and how to secure your AWS resources by managing these identities.

We'll also explore some security best practices when dealing with permissions, access control, and short term vs. long-term credentials.

What is a Root User in AWS IAM?

A root user is the highest level of user in your AWS account; essentially the 'super admin' user. Root users have full, unrestricted permissions to access AWS resources, modify permissions for users and roles, and any other actions within the environment.

You should NEVER use your root user for any day-to-day activities, even administrative ones. Only use it for the most essential tasks that can only be performed with root permissions (such as changing account settings, restoring IAM user permissions, etc).

Ideally, you should create your first IAM user, then securely encrypt and lock away the credentials for your root user.

What are Users in IAM?

Users are the most basic IAM identity, and represent a person who can access resources within your AWS environment. A user can also be an application that can access those resources; for example, a microservice that fetches a customer's account information from your database.

By default, a user has no permissions to perform any tasks. When creating your first user, you can give them certain administrative permissions so they can create and manage other IAM users, groups, and roles.

Take a deeper dive into AWS IAM with our hands-on course! Start learning today.

What are Groups in IAM?

User Groups in IAM simplify the process of giving permissions to users. Instead of assigning permissions individually to each user, you can create a group and assign permissions to that. You can then add users to that group, which automatically gives them the permissions assigned to the group.

For example, if you want to assign admin privilege to a user 'Dave', you can just add Dave to an 'Admins' group that has the right set of permissions. If Dave's responsibilities change at any point, you can simply remove him from the group, and he'll lose the specific permissions granted by the Admins group.

One user can belong to multiple groups. However, groups can't be nested, ie., one group cannot contain another.

What are Roles in IAM?

Roles are similar to users, in that they represent a single identity (person or application), and you can assign it permissions to access resources within AWS. However, they have one key difference: they're not tied to one specific person/application.

Think of it like this: a user is like an identity card — it belongs to one person. It can only give that one specific person access to AWS resources. In this example, user 'Carla' only has access to S3 and Lambda.

A role, on the other hand, is like a temporary access pass. You can assign a role to any user for a temporary task, and once that task is complete, revoke access to that role. Let's say Carla is asked to help out on a project involving EC2. Carla's team leader can assign her a role with the appropriate permissions. Once she's done, they can simply revoke her access to the role itself.

Roles use temporary credentials, which means they don't need you to store or encrypt passwords or access keys. This makes them a far more secure option to give users and services access to resources in AWS.

For this reason, roles are often used to delegate access to users and apps that don't normally have access to your AWS resources.

Best Practices for AWS IAM Security

1. Follow the principle of least privilege

Permissions in AWS IAM are additive, which means there's only 'Allow' rules, and no 'Deny'. By default, an IAM identity has no permissions or privileges.

This isn't by accident! Your approach to managing access should be to follow the principle of least privilege: give the fewest permissions possible for the user/role to perform their task.

2. Enable Identity Federation where possible

Users rely on long-term credentials to get access to your AWS environment. However, these can pose a serious security risk since they can be compromised. If an attacker manages to get their hands on a user's credentials, they can get access to your AWS resources, modify or steal data, and install malware without even being noticed.

The solution? Identity federation! This involves using an Identity Provider (IdP) to authenticate users and give them access to your AWS. The biggest advantage of federated access is that it eliminates the need for passwords and access keys, using temporary credentials exclusively.

AWS supports commonly used open identity standards, including SAML 2.0, OIDC, and OAuth 2.0. For your customer-facing web applications, you can use Amazon Cognito, which supports signing in with identity providers like Apple, Google, Facebook, Amazon, etc.

3. Rotate your access keys regularly

Access keys are long-term credentials, which makes them more susceptible to compromise.

Make sure to regularly rotate and remove your access keys in order to avoid them going stale over time. Rotating them every 90 days or so should be good enough.

4. Remove unused roles, users, policies, etc.

If stale credentials are bad, old and unused IAM identities are worse. An old user or role is a sitting duck for attackers to find and compromise. And if that happens, it's next to impossible to detect their activity, since the monitoring service sees them as just another user.

Make it a habit to watch out for users, roles, and policies that have gone unused for an extended period of time. If it has no immediate utility, it's safer to remove it.

Don't stop at the basics: Become an AWS security guru

Learning the basics of AWS security is just the beginning. Cloud skills are at their highest in demand right now, and becoming an AWS security pro can help you earn more, advance your career faster, and be the MVP on your team.

AppSecEngineer offers 8 amazing courses that feature hands-on labs that let you learn complex concepts and reinforce them with real-world exercises.

You can even try our Playgrounds, which are CTF-style exercises where you solve security problems in realistic labs and cyber-ranges. These are designed for users who want to test their skills in AWS security.

All that and much more is available with a single subscription on AppSecEngineer. Get your account and start learning today!

Source for article
Aneesh Bhargav

Aneesh Bhargav

Aneesh Bhargav is the Head of Content Strategy at AppSecEngineer. He has experience in creating long-form written content, copywriting, producing Youtube videos and promotional content. Aneesh has experience working in Application Security industry both as a writer and a marketer, and has hosted booths at globally recognized conferences like Black Hat. He has also assisted the lead trainer at a sold-out DevSecOps training at Black Hat. An avid reader and learner, Aneesh spends much of his time learning not just about the security industry, but the global economy, which directly informs his content strategy at AppSecEngineer. When he's not creating AppSec-related content, he's probably playing video games.

Aneesh Bhargav