Share This Article
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. It works best if you’re using an Identity Provider with AWS. 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.
Advantages of Using 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.
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
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.
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.
Integrate AWS IAM with JumpCloud
JumpCloud SAML single sign-on (SSO) gives your users convenient and secure access to AWS with a single set of credentials for a true single sign-on experience and automated user and group management. The JumpCloud AWS IAM Identity Center connector can also automate and centralize user and group management for provisioning, de-provisioning, and updating of AWS users and groups from JumpCloud via the SSO solution.
You can try JumpCloud for free to determine if it’s right for your organization. Our customers tell us that asset management is also important for security and IT operations. JumpCloud is enhancing its platform to unify SaaS, IT security, and asset management.
