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!

Understanding the Include Directive

Git's include directive allows you to split your Git configuration into multiple files and include them conditionally based on specific criteria. This feature is particularly powerful for managing different Git identities.

Directory Structure Setup

First, organize your projects into dedicated directories:

~/code/personal/      # All personal projects
~/code/work/          # All work-related repositories

Creating Specialized Config Files

Create separate configuration files for each GitHub account:

Personal Configuration (~/code/personal/.gitconfig)

[user]
    email = personal@email.com
    signingKey = 7D2132F509F82190
[core]
    sshCommand = "ssh -i ~/.ssh/id_ed25519"
[github]
    user = github-personal

Work Configuration (~/code/work/.gitconfig)

[user]
    email = work@email.com
    signingKey = 7D2132F569B82890
[core]
    sshCommand = "ssh -i ~/.ssh/id_ed25519_work"
[github]
    user = github-work

Main Git Configuration

Set up your main ~/.gitconfig file to include these configurations based on directory paths:

[alias]
        co = checkout
        add = add -a
        cm = commit -m
[color]
    ui = auto

[user]
    name = Full Name

[init]
    defaultBranch = main

[includeIf "gitdir:~/code/personal/"]
    path = ~/code/personal/.gitconfig

[includeIf "gitdir:~/code/work/"]
    path = ~/code/work/.gitconfig

[commit]
        gpgSign = true

Benefits of This Approach

• Automatic configuration switching based on project location

• Reduced risk of committing with wrong credentials

• Centralized configuration management

• Easy to add new accounts or modify existing ones

Best Practices

• Store personal projects under ~/code/personal/ directory

• Keep all work projects under ~/code/work/ directory

• Use meaningful names for configuration files

• Regular backup of configuration files

Verification and Testing

To verify your configuration is working correctly, use these commands:

# In a personal repository
cd ~/code/personal/project
git config user.email  # Should show personal email

# In a work repository
cd ~/code/work/project
git config user.email  # Should show work email

Conclusion

With this setup, you can seamlessly manage multiple GitHub accounts while maintaining a clean and organized development environment. The conditional includes handle all the complexity, allowing you to focus on your work without worrying about account switching.

Why Multiple GitHub Accounts?

There are several reasons why you might want to maintain multiple GitHub accounts:

• Separating work and personal projects

• Managing different organizations

• Maintaining distinct online identities

• Compliance with workplace policies

Step-by-Step Configuration Guide

1. Creating SSH Keys

First, generate unique SSH keys for each account. Open your terminal and run:

# For personal account
ssh-keygen -t ed25519 -C "personal@email.com" -f ~/.ssh/id_ed25519

# For work account
ssh-keygen -t ed25519 -C "work@email.com" -f ~/.ssh/id_ed25519_work

2. Setting Up SSH Agent

Add your new SSH keys to the SSH agent:

eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519
ssh-add ~/.ssh/id_ed25519_work

3. GitHub Configuration

Add your public keys to their respective GitHub accounts:

• Copy the content of each .pub file

• Go to GitHub Settings → SSH and GPG keys

• Click "New SSH key" and paste your key

4. SSH Config Setup

Create or modify your SSH config file (~/.ssh/config):

# Personal (Default) account
Host github.com
   HostName github.com
   User git
   IdentityFile ~/.ssh/id_ed25519

# Work account
Host github-work
   HostName github.com
   User git
   IdentityFile ~/.ssh/id_ed25519_work

Using Your Configuration

Cloning Repositories

For personal repositories:

git clone git@github.com:personal-username/repo.git

For work repositories:

git clone git@github-work:work-organization/repo.git

Repository-Specific Configuration

Set up Git configuration for each repository:

# Personal repository
git config user.name "Full Name"
git config user.email "personal@email.com"

# Work repository
git config user.name "Full Name"
git config user.email "work@email.com"

Conclusion

Managing multiple GitHub accounts might seem daunting at first, but with proper configuration, it becomes a seamless part of your development workflow. This setup helps maintain a clean separation between different aspects of your development life while ensuring secure access to all your repositories.