aws

Today, we will learn about IAM Roles and their importance. We will cover key concepts and follow up with a practical demonstration. Let's get started!

Overview

In this blog, we will explore AWS IAM roles by creating a user with no S3 permissions. Then, we will create a role with full S3 permissions. Finally, we will log in as the user with no permissions and switch to the role with full S3 access, demonstrating how roles can be used to manage access control in AWS.

IAM Role

An IAM (Identity and Access Management) role in AWS is an identity that you can create in your AWS account. It has specific permissions and is designed to be assumed by trusted entities such as users, applications, or services.

Unlike an IAM user, a role does not have long-term credentials (password or access keys) associated with it. Instead, it provides temporary security credentials for the purpose of accessing AWS resources.

Why IAM Roles?

Security: Roles use temporary credentials, reducing the risk if credentials are compromised.
Cross-Account Access: Allow users or services from one AWS account to access resources in another account.
Least Privilege Principle: Grant only the necessary permissions for a specific task or session.

Attaching Role directly to a user?

We cannot attach role directly to a user.

Here's why directly attaching roles to users wouldn't be ideal:

If roles were directly attached to users, it would mean the user would always have those permissions. This could be a security risk, as it wouldn't allow for fine-grained control over access.
Without role assumption, users would be stuck with the permissions assigned to their attached role. This wouldn't be flexible for scenarios where a user might need different permissions for different tasks.

Instead, IAM uses a concept called "assuming a role". This means a user (or another trusted entity like an application) can temporarily take on the identity of a role, along with the permissions that role provides. This grants them access to AWS resources for a specific session.

sts:AssumeRole

sts:AssumeRole is an AWS Security Token Service (STS) operation that allows a user or service to obtain temporary security credentials for assuming a different role.

Key Points

Purpose: To grant temporary access to AWS resources based on the permissions of a specified role.
How it Works:
- Request: A user or service calls sts:AssumeRole and specifies the ARN (Amazon Resource Name) of the role they want to assume.
- Verification: AWS STS checks if the caller is allowed to assume the role based on the role's trust policy.
- Temporary Credentials: If allowed, STS issues temporary security credentials (Access Key ID, Secret Access Key, and Security Token).
Temporary Credentials:
- Access Key ID: Like a username for programmatic access.
- Secret Access Key: Like a password, used together with the Access Key ID.
- Security Token: Adds an additional layer of security and has a short expiration time (usually up to 1 hour).
Session with Assumed Role:
- Use Temporary Credentials: With these credentials, the user can access AWS resources as allowed by the role, for a limited time.

Trust Policy vs. Role Policy

Trust Policy:

Determines who can assume the role.
Attached to the role and uses sts:AssumeRole.

Role Policy:

Determines what actions can be performed when the role is assumed.
Attached to the role and specifies allowed actions and resources.

Dirty Hands

Alright, let's get our hands dirty.

To begin with, let's create a new user.

Go to IAM section, and on Users, click on Create user.

Click on Next until you create a user.

I've created a User named testuser.

Now, let's create a Role.

We are granting permission to users, applications, or services from different AWS accounts (including accounts we own and accounts owned by others) to access and perform specific operations in our AWS account

Click on Next.

Search for s3 and select the policy where we're granting full s3 access for this role.

Click on Next.

Provide a suitable role name.

This trust policy allows any user or entity belonging to the AWS account with ID 767398070747 to assume the role.

When someone from that account tries to assume the role (using the sts:AssumeRole API operation), as long as the account ID matches the one specified in the trust policy, they will be granted temporary security credentials to act with the role's permissions for a limited time.

While, it is the permissions policy we'd given earlier.

Click on Next and Create a role.

Our role has been created.

Now, let's log in as recently created testuser. For that, go to Dashboard, and copy the Sign-in URL.

Open private window, paste the link and login as recently created New User.

You either provide Account ID or alias. I had created alias for ease.

I've logged in as testuser.

Now, let's try to see the list of buckets if there's any.

We do not have the permissions to list buckets.

Now, let's assume the s3Access role for this testuser.

For this, we've to go back to the iamadmin console and proceed.

After you're in your iamadmin console, Click on Role, select the role that you'd created and copy the ARN.

Save it to somewhere for now.

Now, click on Users and select the testuser.

Scroll a bit and click on Add permissions.

Click on Create inline policy.

On Action, type sts:AssumeRole

Also, paste the copied ARN in Resource field.

This policy allows users from the account ID 767398070747 to assume the "s3Access" role. Once they assume the role, they can temporarily act with the permissions assigned to that role.

Click on Next and provide relevant policy name and Create Policy.

Ok, now our testuser can assume that role that grants the user full access to s3 services.

Head up to testuser console.

As we discussed earlier, role can't be assigned directly to the user. So, we've to switch role.

Click on Switch role.

Provide the details and click on Switch Role.

Now we can see We've switched our role, and we can see no restrictions as before. We've assumed a role that has full access to s3 services. We can perform different operations on s3 for a limited time.

And, to go back to our own profile, simply click on Switch back.

Now, as we've switched back, and we have no longer permissions to perform operations on s3.

In this way, by carefully crafting trust policies, we can grant controlled access to our AWS account's resources. We can specify exactly who (or what) can assume a role and what actions they can perform while acting under that role's permissions. This allows for secure and granular access management within your AWS environment.

Now, time to clean up.

Head back to your iamadmin console.

Click on roles and delete the created role.