Unleash Your Workloads: Secure AWS Access from Anywhere with IAM Roles Anywhere

In today's hybrid cloud landscape, securely connecting your on-premises servers, edge devices, and containerized applications to AWS services is a critical challenge. Hardcoding AWS access keys is a security nightmare, leading to potential breaches and compliance headaches. Enter AWS IAM Roles Anywhere, a powerful service that empowers your workloads outside of AWS to seamlessly and securely access your cloud resources using the trust of X.509 certificates.

This post will guide you through the process of setting up AWS IAM Roles Anywhere, from generating your own Certificate Authority (CA) to configuring your local environment for secure access.

The Power of Trust: X.509 Certificates

At the heart of IAM Roles Anywhere lies the concept of trust established through X.509 certificates. Instead of long-lived access keys, your external workloads present a short-lived credential issued based on a certificate signed by a trusted Certificate Authority (CA). This significantly enhances your security posture by:

• Eliminating static credentials: No more hardcoded access keys lying around.

• Leveraging short-term credentials: Credentials automatically expire, reducing the impact of potential compromise.

• Centralized trust management: Your CA becomes the single source of truth for authenticating external workloads.

Step 1: Forge Your Trust Anchor – The Private Root CA

The first crucial step is to generate your own private Root CA. This Root CA acts as the ultimate trust anchor within AWS IAM Roles Anywhere. We'll use OpenSSL for this, a powerful open-source toolkit for managing SSL/TLS certificates.

Prerequisites:

• OpenSSL installed on your system.

• A working directory, commonly ~/.aws, to store your certificate files.

• An openssl.cnf file (we'll call it v3.ext for this example) with basic CA constraints and identity attributes.

Creating Your v3.ext OpenSSL Configuration File:

Create a file named v3.ext in your ~/.aws directory with the following content. Remember to replace the placeholder values for Country, State, City, Organization, Organizational Unit, Commo with your actual details. Leave commonName and emailAddress blank.

[ req ]
default_bits        = 2048
distinguished_name  = req_distinguished_name
x509_extensions     = v3_ca

[ req_distinguished_name ]
countryName                     = Country Name (2 letter code)
countryName_default             = US
countryName_min                 = 2
countryName_max                 = 2

stateOrProvinceName             = State or Province Name (full name)
stateOrProvinceName_default     = California

localityName                    = Locality Name (eg, city)
localityName_default            = San Francisco

0.organizationName              = Organization Name (eg, company)
0.organizationName_default      = ABC Inc.

organizationalUnitName          = Organizational Unit Name (eg, section)
organizationalUnitName_default  = DevOps

commonName                      = Common Name (e.g. server FQDN or YOUR name)
commonName_max                  = 64

emailAddress                    = Email Address
emailAddress_max                = 64

# --------------------------------------------------------------------
# For creating a root or intermediate CA certificate
[ v3_ca ]
subjectKeyIdentifier    = hash
authorityKeyIdentifier  = keyid:always,issuer:always
basicConstraints        = critical, CA:true
keyUsage                = critical, digitalSignature, cRLSign, keyCertSign

Generating the Private Root CA Key and Certificate:

Now, navigate to your ~/.aws directory in your terminal and run the following commands:

# Generate the private key for your Root CA
openssl genrsa -out PrivateRootCA.key 2048

# Generate the self-signed Root Certificate (valid for 10 years)
openssl req -new -x509 -days 3650 \
    -key PrivateRootCA.key \
    -out PrivateRootCA.pem \
    -config v3.ext

You'll be prompted for your Country Name, State or Province Name, Locality Name, Organization Name, and Organizational Unit Name. Provide these as per your v3.ext file. Crucially, leave the Common Name and Email Address fields blank when prompted.

To inspect the root certificate and verify that it was created successfully, you can use:

openssl x509 -text -noout -in PrivateRootCA.pem

Step 2: Empower Your Workloads – The Client Certificate

With your Root CA established, you can now issue client certificates for your external workloads. Each workload that needs to access AWS will have its own unique client certificate.

Updating v3.ext for Client Certificates:

For client certificates, we need to adjust the v3.ext file to include non-CA certificate settings. Modify your v3.ext file to look like this (add the [ v3_cert ] section):

[ req ]
default_bits        = 2048
distinguished_name  = req_distinguished_name
x509_extensions     = v3_ca

[ req_distinguished_name ]
countryName                     = Country Name (2 letter code)
countryName_default             = US
countryName_min                 = 2
countryName_max                 = 2

stateOrProvinceName             = State or Province Name (full name)
stateOrProvinceName_default     = California

localityName                    = Locality Name (eg, city)
localityName_default            = San Francisco

0.organizationName              = Organization Name (eg, company)
0.organizationName_default      = ABC Inc.

organizationalUnitName          = Organizational Unit Name (eg, section)
organizationalUnitName_default  = DevOps

commonName                      = Common Name (e.g. server FQDN or YOUR name)
commonName_max                  = 64

emailAddress                    = Email Address
emailAddress_max                = 64

# --------------------------------------------------------------------
# For creating a root or intermediate CA certificate
[ v3_ca ]
subjectKeyIdentifier    = hash
authorityKeyIdentifier  = keyid:always,issuer:always
basicConstraints        = critical, CA:true
keyUsage                = critical, digitalSignature, cRLSign, keyCertSign

# --------------------------------------------------------------------
# For end-entity (leaf) certificates like client/server certs
[ v3_cert ]
authorityKeyIdentifier  = keyid,issuer
basicConstraints        = critical, CA:false
keyUsage                = critical, digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment

Generating the Client Private Key, CSR, and Certificate:

Now, generate the client's private key, a Certificate Signing Request (CSR), and then sign the CSR with your Root CA:

# Generate the private key for the client
openssl genrsa -out clientEntity.key 2048

# Generate the Certificate Signing Request (CSR) for the client
openssl req -new -key clientEntity.key -out clientEntity.csr -config v3.ext -extensions v3_cert

# Sign the client's CSR with your Root CA (valid for 1 year)
openssl x509 -req -in clientEntity.csr -CA PrivateRootCA.pem -CAkey PrivateRootCA.key -CAcreateserial -out clientEntity.pem -days 365 -sha256 -extfile v3.ext -extensions v3_cert

You'll be prompted for identity attributes for the client certificate. This time, include a Common Name (e.g., clientEntity).

Step 3: Configure AWS IAM Roles Anywhere

Now that you have your certificates, it's time to set up IAM Roles Anywhere in the AWS console.

1. Log in to the AWS Management Console and navigate to the IAM service.

2. In the left-hand navigation pane, select Roles Anywhere.

3. Create a Trust Anchor:

   • Click on Create trust anchor.

   • Choose External certificate bundle.

   • Upload your PrivateRootCA.pem file.

   • Give your Trust Anchor a meaningful name (e.g., MyOnPremRootCA).

4. Define a Profile:

   • Click on Create profile.

   • Give your Profile a name (e.g., OnPremWorkloadProfile).

   • Associate one or more IAM Roles with this profile. These are the roles your external workloads will assume.

5. Configure IAM Role Trust Policies:

   For each IAM role associated with your profile, you must modify its trust policy to allow rolesanywhere.amazonaws.com to assume the role.

   Navigate to the IAM role, go to the Trust relationships tab, and click Edit trust policy. Add the following to the policy:

    {
      "Version": "2012-10-17",
      "Statement": [
        {
          "Effect": "Allow",
          "Principal": {
            "Service": "rolesanywhere.amazonaws.com"
          },
          "Action": "sts:AssumeRole",
          "Condition": {
            "StringEquals": {
              "aws:SourceArn": "arn:aws:rolesanywhere:<region>:<account-id>:profile/<your-profile-name>"
            }
          }
        }
      ]
    }
   

   Replace <region>, <account-id>, and <your-profile-name> with your actual AWS region, account ID, and the name of the profile you created.

Step 4: Access AWS from Your Workload with aws_signing_helper

AWS provides aws_signing_helper, a utility that facilitates the signing of requests and retrieval of temporary credentials using your client certificate and private key.

Install aws_signing_helper:

Download and install aws_signing_helper for your operating system. Make sure it's in your system's PATH.

Configure AWS CLI with credential_process:

The credential_process feature in the AWS CLI allows you to execute an external command to retrieve credentials. This is where aws_signing_helper shines.

Open your AWS CLI configuration file (usually ~/.aws/config) and add a new profile:

[profile rolesanywhere-test]
credential_process = aws_signing_helper credential-process \
  --certificate ~/.aws/clientEntity.pem \
  --private-key ~/.aws/clientEntity.key \
  --trust-anchor-arn arn:aws:rolesanywhere:<region>:<account-id>:trust-anchor/<your-trust-anchor-id> \
  --profile-arn arn:aws:rolesanywhere:<region>:<account-id>:profile/<your-profile-id> \
  --role-arn arn:aws:iam::<account-id>:role/<your-iam-role-name> \
  --region <region>

Important:

• Replace placeholders:

  • <region>: Your AWS region (e.g., us-east-1).

  • <account-id>: Your AWS account ID.

  • <your-trust-anchor-id>: The ID of your Trust Anchor (found in the IAM Roles Anywhere console).

  • <your-profile-id>: The ID of your Profile (found in the IAM Roles Anywhere console).

  • <your-iam-role-name>: The name of the IAM role you want to assume.

• Permissions: Ensure the user running aws_signing_helper has read access to clientEntity.pem and clientEntity.key.

Testing Your Setup

Now, from your external workload (your local machine in this example), you can use the configured AWS CLI profile to access AWS services:

aws s3 ls --profile rolesanywhere-test
aws sts get-caller-identity --profile rolesanywhere-test

If everything is configured correctly, you should see your S3 buckets listed or the details of the assumed IAM role, all without ever needing to use static access keys!

Conclusion

AWS IAM Roles Anywhere provides a robust and secure mechanism for extending AWS access to your workloads running outside of the AWS cloud. By leveraging X.509 certificates and short-term credentials, you can significantly enhance your security posture and simplify credential management. This approach is fundamental for building secure and compliant hybrid cloud architectures, enabling seamless integration between your on-premises and cloud environments. Start your journey towards a more secure and efficient hybrid cloud with IAM Roles Anywhere today!