AWS: Secure Your Environment and Applications by Using Temporary Access Credentials

Photo by Silas Köhler on Unsplash

Whenever you find yourself starting to type an AWS Access Key, I urge you to PAUSE. Ask yourself, “Is there a better way?” It doesn’t matter if you are building a new application, setting up a new development environment, or integrating with another service.

If you have experience in DevOps, you know that investing time upfront to script and automate your infrastructure improves the speed and quality of future deployments. The same goes for security, where investing time helps ensure that your environment and applications are less likely to be hit with a security breach, which is arguably worse than having to provision infrastructure manually.

Temporary, Limited-Privilege Access Credentials

Thankfully, there are several ways we can help secure our environment and applications. One way is to move away from fixed API access keys towards the use of temporary, limited-privilege access credentials. Short-term credentials behave just like long-term credentials except that they:

1. Expire after a short period of time, and
2. Are created dynamically and never stored with the user

This offers several key benefits:

• You no longer need to distribute or embed long-term credentials in applications​.
• You can provide access to resources without creating AWS identities for them​.
• You don’t have to rotate the access keys.

AWS Security Token Service (STS)

AWS provides several methods to obtain temporary access credentials depending on the use case. Behind the scenes, they all use the AWS Security Token Service (STS). AWS STS enables you to request temporary, limited-privilege credentials for:

1. AWS Identity and Access Management (IAM) users
2. Users authenticated via other identity providers such as Azure Active Directory
3. Roles (e.g., a Lambda execution role) assuming other roles

Let’s explore a variety of use cases.

Use Case 1: AWS CLI

The conventional way to access AWS via the AWS CLI is to create an IAM user and an access key. The access key is then placed into your ~/.aws/credentials file.

But what if those credentials accidentally get exposed? Mistakes do happen, so why take the risk?

If your organization is using Active Directory (AD) to provide federated access to AWS, check out the aws-azure-login tool. The tool allows you to sign in via the command line using your AD credentials, and then provides you with temporary credentials to access AWS. Once configured, the tool can be used to automatically renew expired AWS credentials without having to re-enter your AD credentials.

aws-azure-login tool architecture

If your organization is using the AWS Single Sign On (SSO) service, you can use AWS CLI version 2 to automatically retrieve temporary credentials. In the previous version (V1), you had to copy and paste these credentials from the AWS SSO conso Version 2 increases developer productivity by eliminating that manual step.

After configuration, a named profile is created that contains the SSO parameters necessary to retrieve the credentials.

Named profile example after AWS CLI SSO configuration (Source)

You then use the aws sso login command to obtain the temporary credentials. The CLI will automatically renew expired credentials as long as you are signed in to AWS SSO. AWS SSO uses the session duration setting on the permission set to control how long you can access AWS before requiring a new set of credentials. This can range from 1 hour up to 12 hours. It is recommended that you do not set the session duration length longer than is needed to perform the role.

One of the great things about AWS SSO is that it can integrate with Active Directory, AWS’s own SSO directory service, or any SAML-based identity provider. If you are not already using an identity provider in your AWS architecture, you should consider doing so because of the security benefits you can obtain by leveraging tools like these.

For more info on how to configure the CLI to use SSO, please visit:
https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-sso.html

Use Case 2: EC2 Hosted Applications

If your applications run on EC2 instances, you should configure the instances to use an IAM role. The role supplies temporary credentials that applications can use to make the calls to AWS resources. If you create the role via the AWS console, simply assign an IAM role to the instance. If you are using an API or CLI, you need to create an instance profile and attach it to the EC2 instance. The instance profile contains the role and provides the role’s temporary credentials to the application.

IAM role configuration during EC2 setup

Use Case 3: Non-EC2 Hosted Applications

If you are not using EC2 instances to host your application, you can use the AWS Security Token Service API to obtain temporary credentials and use them to make subsequent calls.

The following example demonstrates how to invoke the STS API to obtain temporary credentials and use them to call another AWS resource.

Python example to retrieve temporary credentials via STS and then call Amazon S3

To run this code successfully:

• The originating IAM user/role must allow the STS:AssumeRole action on the destination role resource.

{
   "Version": "2012-10-17",   
   "Statement": [{
       "Effect": "Allow",
        "Action": "sts:AssumeRole", 
        "Resource": "arn:aws:iam::12345678:role/S3ReadAccess"
   }]
}

• The destination IAM role (i.e. S3ReadAccess) must trust the entity looking to assume the role.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::12345678:username"
      },
      "Action": "sts:AssumeRole",
      "Condition": {}
    }
  ]
}

Use Case 4: Direct API Calls

AWS offers Software Development Kits (SDKs) for several programming languages. If you are using a programming language for which there is no AWS SDK, however, you will need to write custom code to send HTTP requests to AWS. Below are the key steps:

1. Invoke the AWS STS API to obtain the temporary credentials
2. Sign the request like you normally would when using long-term credentials with the provided access key ID and secret access key
3. Add the session token to the HTTP header or query string parameter called X-Amz-Security-Token

Use Case 5: Web / Mobile App Authentication via Amazon Cognito

AWS Cognito is a service that provides authentication and authorization functionality to web and mobile applications.

Cognito consists of User Pools and Identity Pools. A user pool is simply a directory service. Identity pools are a type of federated identity that allow you to create unique identities and assign permissions. The identity pool can contain both users from a Cognito user pool and users from an external identity provider (i.e. Facebook, Google, etc.)

Authenticated Cognito users obtain a set of temporary, limited privilege credentials based on the IAM role associated with that pool. You can also create a separate role for guest users who are not authenticated.

Here are two common use cases for Cognito:

Scenario 1: Mobile Application Authentication

You have a mobile application that allows end-users to login with their Facebook account. The application uses DynamoDB and S3. You can use Cognito to authenticate users and provide them the desired access levels to your AWS resources.

To configure this:

1. Register your application with Facebook and get an App ID
2. Configure a Cognito Identity Pool to use Facebook as the authentication provider using the App ID you obtained from Facebook
3. In your application, use the appropriate SDK to obtain temporary access credentials using the Cognito Pool ID

Cognito authentication using Facebook as the identity provider

Scenario 2: API Gateway Protection

If you are using API Gateway, Cognito can be used to control who can access your API. You first create a Cognito User Pool authorizer and then configure your API to use that authorizer. After the API is deployed, the end-user signs in to the user pool, obtains an identity or access token, and then calls the API using the token.

For more info, visit: https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-enable-cognito-user-pool.html

Use Case 6: AWS Internet of Things (IoT)

AWS offers a unique IoT credentials provider that lets devices authenticate AWS requests with an X.509 certificate. After the certificate is validated by AWS IoT, AWS STS provides temporary access credentials back to the device. Since only you hold the private key (not AWS), you can burn these private keys into secure storage on the actual devices themselves.

AWS IoT certificate-based authentication

Note: This diagram above is a slightly modified version of the diagram provided in this blog post.

Using Temporary Access Credentials is a Best Practice

Although this article was focused on AWS, the same principle applies for all service providers. Steer clear of fixed access keys where at all possible. Make use of temporary, limited-privilege access credentials. It doesn’t matter how big or small the application is. The investment upfront to “do it right” could easily save you from getting burned in the future.

Happy Developing!