We will be exploring the AWS Security Token Service (STS) to work with temporary security credentials. We will look at how they are set up and used, and then go through an example to put it all together.

In short, STS enables flexibility that provides granular control of more than one AWS service for a certain amount of time. AWS STS supports the following APIs:

  • AssumeRole
  • AssumeRoleWithSAML
  • AssumeRoleWithWebIdentity
  • DecodeAuthorizationMessage
  • GetCallerIdentity
  • GetFederationToken
  • GetSessionToken

Throughout the article, we will focus on AssumeRole, which can give a user temporary access to an AWS resource that they don't normally have access to.

An example will describe everything. To begin, we will create a user and assign them full EC2 access for their day job. Our user, JoeBlogs, will be assigned console access only, although you could allow for programmatic access or both together:

Creating our new user

Creating our new user

Our user, JoeBlogs, has been asked by his manager to provide the names of buckets and when they were created. JoeBlogs doesn't need access to s3 buckets normally, and since it's a temporary task, he only needs a short amount of time to get this information.

To start with, create a policy that will allow access to list the S3 buckets. Add the below JSON code as the policy:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "s3:GetBucketLocation",
                "s3:ListAllMyBuckets"
            ],
            "Resource": "*"
        }
    ]
}

For this demo, I have named the policy MyS3ListPolicy:

Creating the S3 policy to list buckets

Creating the S3 policy to list buckets

Now that we have the policy in place, we must create a role to attach the policy to. Under roles, click Create. From the list of services, choose S3 and the S3 use case. Attach the policy, MyS3ListPolicy, which we previously created. Add a role name (in my case, I've called it temp_s3_list), and then create the role:

IAM role to view bucket listings

IAM role to view bucket listings

To complete the role, we need to edit the trust relationship. Open the role:

Editing the trusted policy

Editing the trusted policy

Under the Trust Relationship tab, click Edit trust relationship.

The first thing to notice is the Action parameter, which calls the sts:AssumeRole to provide temporary credentials. The role has been further locked down by adding the ARN of our user, JoeBlogs, to the principal parameter. This will prevent the role from being used by any other user.

Copy this policy to the trust relationship, changing the ARN of the user to the name of your new user's ARN:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::81815505****:user/JoeBlogs"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

Once you’ve updated the trust relationship, the IAM role summary will update (you might need to refresh the screen):

IAM role summary

IAM role summary

I've highlighted two areas of interest on the summary page:

Maximum session duration allows for the duration to be expanded from the default 1 hour to 12 hours:

Amending the duration of the session

Amending the duration of the session

Give this link to users who can switch roles in the console: You can either use this link, which will populate the account or role fields for you, or from the top right of your screen, click the user name, and choose switch role from the options listed.

This is what will allow the user, JoeBlogs, to make use of this temporary role. Now is a good time to see this in action!

I have signed in to the AWS console as JoeBlogs:

Signing in with JoeBlogs

Signing in with JoeBlogs

Checking S3 shows us that JoeBlogs does not have access to see any buckets or details:

Access error when viewing S3

Access error when viewing S3

Now we will use the link provided from the IAM role summary to switch roles. You can manually construct the link for yourself:

Creating your own link

Creating your own link

The AWS Switch Role screen is shown below with the pre-populated fields. I've added a

display name to make it easier to distinguish the temporary role

AWS switch role screen

AWS switch role screen

When looking at the user details in the top right-hand corner, we can clearly see the temporary role name:

Joes temporary role

Joes temporary role

The option to switch back to JoeBlogs is available to return to the main console with the original account.

Checking S3 now shows the temporary credentials are working, allowing us to view the bucket details:

S3 view with temporary credentials

S3 view with temporary credentials

In the example, you've seen us call the AssumeRole API when the user was signed in as an IAM user. This can also be extended to access different AWS accounts as well.

The main purpose of STS is to provide temporary credentials to AWS resources. These credentials are different from standard IAM roles in that they automatically expire and are not usable after a short period of time. The credentials for STS are not stored with the user or service. Instead, a token is attached to an API call or access request. No credentials are passed to or from the user or service.

This is only a small but useful area of STS. Identity federation can be provided to a non-AWS user for temporary access. This is done with AWS Cognito to create unique identities. An ID provider, such as Google or Facebook, can be used to authenticate. All of these features can be created and used by the various AWS SDKs and CLI tools.

STS fully supports AWS CloudTrail to audit calls made to the AWS account, allowing for successful and non-successful requests to be recorded as well as who made the request and when.

Subscribe to 4sysops newsletter!

I hope this article and the example given have provided a basic idea of how you can use STS. As I said, there are many more concepts and areas to explore with AWS temporary security tokens that offer trusted ways to access AWS resources.

0
0 Comments

Leave a reply

Please enclose code in pre tags

Your email address will not be published. Required fields are marked *

*

© 4sysops 2006 - 2021

CONTACT US

Please ask IT administration questions in the forums. Any other messages are welcome.

Sending

Log in with your credentials

or    

Forgot your details?

Create Account