CODEWITHSUNDEEP
amazon-web-servicesaws-sdkaws-cliaws-sts
SRaj
SRaj

Reputation: 1338

AWS STS use cases and advantages

I am confused about the use cases and advantages of STS. As per the documentation, it is to temporarily acquire a role to perform tasks within AWS which are not available for the IAM user or service. Please note that I am talking about programmatic access (NOT console access)

For example, an IAM user may not have S3 permissions. As per my understanding:

  1. He can get temporary access key/token by contacting AWS STS and get access key and secret for S3.

  2. With those temporary credentials, he can access S3.

My questions are:

  1. To get temporary credentials from AWS STS, he still need his existing access token (permanent) and secret, right?

  2. If his existing access token and secret are leaked, an attacker can still use it to first get temporary credentials from STS and then access S3, right? I understand that the attacker won't be able to directly access S3 using his permanent access token and secret.

I am trying to wrap my head around its correct use cases. I know that I'm confused, but maybe I'm thinking in loops.

Thanks in advance.

Upvotes: 3

Views: 2542

Answers (2)

gusto2
gusto2

Reputation: 12075

I will try to extend and generalise the first answer. The example with the Fire Warden is good to understand, but I feel it needs some extension.

Generally the AWS STS is able to return role credentials based on other identity or role credentials (aws or other identity provider).

The original credentials can be either AWS credentials from the same account, another account, federated token (e. g. supported social networks) or even a custom identity broker.

see https://docs.aws.amazon.com/cli/latest/reference/sts/index.html

Common use cases:

  • privilege elevation - this is already mentioned, AssumeRole allows to become another role within the same or different aws account

  • authorization to aws resources for identities authenticated a other way (AD, SAML, OIDC,..), see services AssumeRoleWithSAML or AssumeRoleWithWebIdentity.

  • authorization to aws resources with custom authorization, see GetFederationToken.

To get temporary credentials from AWS STS, he still need his existing access token (permanent) and secret, right?

By default AssumeRole, the user needs to be authenticated and having permission to assume the role.

If his existing access token and secret are leaked, an attacker can still use it to first get temporary credentials from STS and then access S3, right?

yes

I understand that the attacker won't be able to directly access S3 using his permanent access token and secret

if you configure the S3 or IAM permissions that way

Upvotes: 4

John Rotenstein
John Rotenstein

Reputation: 269340

They don't so much "contact AWS STS and get access key and secret for S3". Rather, they call AssumeRole() on an IAM Role that has permission to access Amazon S3. Then, using the temporary credentials that are returned, they can access S3.

Your confusion seems to be mostly around the use-case for IAM Roles. I like to explain it by way of a story...

I am a Fire Warden in my office at work. If the Fire Alarm activates, I go to a cupboard, put on a red helmet, then walk around the office and direct people to the stairwell. Since the alarm is sounding and I'm wearing a red hat, people (mostly) do what I tell them. However, if it was a normal day with no alarm sounding and I wasn't wearing the red hat, and I asked them to exit the office via the stairwell, they would likely look at me strangely and ignore my request. The difference is that I assumed the role of a Fire Warden, which gave me extra permissions.

So, as a normal person, I can't order people out of the office. However, once I assume the role, I have extra permissions.

This is a good practice for IT systems, too. The Systems Administrator in your company probably has permissions in your AWS Account to do anything. However, it would be a bad practice for them to use an account with such powers on a day-to-day basis. Instead, their IAM User account should just have normal permissions but, if they want to do Admin-type stuff, they have the ability to Assume an Admin Role and then do powerful stuff. When they're finished, they should exit the role and keep being a normal user. This is much 'safer', since they can't accidentally do something powerful when they are a 'normal user'.

Amazon Security Token Service (STS) is also used to provide permissions to software running on Amazon EC2 instances. In this case, an IAM Role is assigned to the EC2 instance and the EC2 service 'assumes' the role on behalf of the instance. It then provides the temporary credentials via the EC2 Instance Metadata service. In this example, there was no IAM User that assumed the role. Instead, the EC2 service assumed it on behalf of the instance.

STS can also provide cross-account permissions. For example, an IAM User in Account A could call AssumeRole() on an IAM Role in Account B. If they have permission to do this, then they will be given temporary credentials that are associated with Account B. This is required because credentials from one Account can never be used to manage resources in another Account.

There are other reasons for using temporary credentials too, such as using MFA tokens, federated logins where there are no IAM Users, and reducing your own set of permissions.

Upvotes: 6

Related Questions