Creating Temporary Credentials Using Assume Role in AWS

Given that malicious actors and cyber attacks have become commonplace, all risks must be minimized when granting external access to your cloud. While most organizations are aware of the need for vigilance, they aren’t sure how. 

There are many best practices to follow for an AWS integration, but today we’ll be focusing on Assume Role, aka letting third parties assume an IAM role for limited session duration. Let’s dive right in.

What is Assume Role in AWS?

Assume Role provides a set of temporary security credentials to access AWS resources you might not have access to in normal conditions. These temporary credentials consist of a security token, an access key ID, and a secret access key.

The credentials generated by Assume Role can be used in making API calls to AWS services with the following exception: calling the AWS STS GetFederationToken or GetSessionToken API operations.

How Does an Assume Role Work?

When you need to grant external access to a third-party service, it can assume an IAM role to request temporary credentials and access to your AWS resources for a specified session duration. This way, you won’t need to share long-term credentials like a password or access key associated with it with third parties.

You can securely delegate access to users, services, or applications that normally don’t have access to your resources. For example, you might grant access to your account to a third-party service so that it can operate audits on your resources (which is the case with Resmo; we’ll discuss that later in the article.)

Advantages of Using Assume Role

advantages of using AWS assume role
  • Temporary credentials

You can use an Assume Role to obtain temporary security credentials. That way, you reduce the risk of accidentally exposing your long-term credentials.

  • User configurations

Session duration times for the temporary credentials are configurable. AWS Security Token Service (STS) designates default session times for the credentials. They expire after passing the specified time limit.

  • Improved security

With Assume Role, third parties can only access temporary credentials. Combined with an external ID condition, using Assume Role for third-party integrations improves security hygiene and prevents unauthorized access.

  • Session permissions can be revoked.

If you need to stop an assumed IAM role from accessing your resources, you can revoke the session permissions from a role.

Laying Down The Basics

First things first, AWS provides access to AWS resources through IAM roles. That means, in order to access a resource in an AWS account, you need an IAM role with the necessary permissions. The process is better understood if we pass through the tip of the iceberg. Let’s break it down into key concepts.

Resource: A resource in AWS is an object within a service such as an IAM user, an Amazon S3 bucket, or an Amazon EC2 instance. 

You might also like our article about the most common Amazon S3 misconfigurations.

AWS Identity Access Management (IAM):

AWS Identity Access Management (IAM) helps you control and define who is authenticated (successfully signed in) and authorized (have proper permissions) to access and use your resources. Requested operations can be performed after AWS approves the request. 

IAM Roles:

An IAM role is an IAM identity that you can create with specific permissions. It provides a mechanism to grant access to your AWS resources without needing to give away your long-term credentials. Unlike an IAM User, which is associable with one person, an IAM role is assumable by anyone

  • An IAM role does not have long-term credentials such as a password.
  • It provides temporary credentials limited to your role session.
  • Each Role comes with a trust policy determining the entities that can assume the Role.
  • Each Role also has a permission policy that specifies what can be done with the Role.

External ID:

A recommended best practice when granting resource access to a third party is using an IAM role with an external ID. An external ID is a unique identifier that you can pass to the AssumeRole API of the Security Token Service. You can use an external ID in the condition element of a role’s trust policy. That way, only someone with the exact external ID can assume the Role.

Long-Term Credentials vs. Temporary Credentials

long-term vs temporary credentials in AWS

To assume a role, you need to use the Security Token Service (STS) that generates the temporary credentials to use the Role. When you assume a role, you receive credentials with which you can make API calls. These credentials allow you to act in the assumed Role until they expire. They are separate from your original credentials, so you can use both simultaneously for different API calls. They also look different as in the following schema. 

Integration with Assume Role & External ID Combination

Using an external ID as an additional parameter when assuming a role is optional but recommended to prevent unauthorized access. It is advised, especially when you need to give a third-party access to your AWS resources. I’ll go over a scenario to demonstrate the process.

  • Let’s say you hire a third-party company called Example Corp to monitor your AWS account for cost optimization. There are many other companies for which Example Corp monitors AWS resources.
  • In such a case, don’t give Example Corp access to an IAM user and your long-term credentials. Instead, use an IAM role with temporary credentials so that they can access your AWS resources using the temporary credentials you provided. But there’s still a problem
  • The partner requests a role ARN (Amazon Role Name) from each customer. However, if another Example Corp customer guesses or gets your ARN, that customer could access your AWS resources.
  • So, even if you use the Assume Role, an unauthorized user could gain access to your resources. That’s called the confused deputy problem

The Confused Deputy Problem

AWS Assume Role example graphic
Source:AWS

An unauthorized user could exploit the confused deputy problem to access your AWS resources. 

  • Let’s say that AWS1 is your account.
  • AWS1:ExampleRole is a role in your AWS account. The trust policy of this Role trusts your partner (Example Corp) by defining Example Corp’s account as authorized to assume the Role.

When you start using the partner’s service, you give them the ARN of AWS1:ExampleRole to assume the Role. Example Corp uses that ARN to obtain temporary security credentials to access resources in your AWS account. In this scenario, you’re entrusting the partner as a “deputy” that can act on your behalf.   

Another customer of Example Corp uses the same service. Let’s assume that this other customer learned or guessed the ARN of AWS1:Example. So, that customer also gives the ARN of AWS1:ExampleRole to the partner to assume the Role. When the customer asks Example Corp to access the AWS resources in “its” account, Example Corp will use the AWS1:ExampleRole to access your resources. 

This way, the other customer could gain access to your AWS resources as it tricked Example Corp into unknowingly acting on your resources. And now, the Example Corp is a “confused” deputy.

The cause of vulnerability here is that Example Corp, as the IAM User, did not pass an external ID when assuming a role.

Resmo Integrates with AWS using Assume Role

As a cloud and SaaS asset visibility, security, and compliance solution, Resmo requires access to your resources in order to integrate with your AWS account. We treat your security as our number one priority, which is why we use both Assume Role and external ID when accessing your resources. 

How does the integration work?

Your Resmo AWS integration consolidates resources by establishing a trust relationship in your account once you create an IAM role in your AWS account and specify in your trust policy to let Resmo assume the Role. You can manually install our AWS integration or use AWS CloudFormation. (See the developer documentation for more details.)

What does Resmo require for an AWS integration?

  • Account ID
  • Role Name
  • External ID

The integration and continuous cloud monitoring process remain secure and unique to your account with account ID, assume Role, and external ID.

Key Takeaways

  • You can use Assume Role to provide temporary credentials to a third-party service. This way, third parties can assume an IAM Role and access your AWS resources for specified session duration.
  • Once the session of the Assume Role expires, third parties cannot access your resources.
  • Use Assume Role which provides temporary security credentials instead of giving your long-term access keys. 
  • You can reduce the risk of accidental exposure by passing an external ID when assuming a role.

The process may seem a bit confusing at first, but once you grasp the basics, it all falls into place. Don’t forget to sign up to our newsletter to get notified about more content like this (at reasonable intervals).

Have you watched our intro video yet? - Take a quick look.

Continue Reading