Empowering Non-AWS Workloads With AWS IAM Roles For Secure Access

Can you allow access to a client outside of the AWS cloud? Yes, you can. However, it gets complicated to achieve this thanks to the recently launched feature “AWS IAM Roles Anywhere”. This feature allows you to provide temporary credentials to clients/applications outside the AWS cloud.

However, this can be achieved through IAM roles also but it has the following drawbacks.

Drawbacks of using IAM keys

  • AWS IAM keys will be a long-lived credential.
  • Regular key rotation is required for AWS IAM keys.

AWS IAM Roles Anywhere allows us to use private key infrastructure (PKI) to generate temporary credentials for accessing IAM Roles outside the AWS cloud.

1. What is AWS IAM Roles Anywhere?

  • It is useful to acquire temporary security credentials in IAM for non-AWS workloads such as servers, containers, and applications that run outside of AWS.
  • Non-AWS workloads must use X.509 certificates issued by a certificate authority (CA) to avail of the features of AWS IAM Roles Anywhere.

A Certificate Authority (CA) is a trusted organization that verifies websites/other entities to know with whom you are communicating over the internet.

  • Now you have to register the certificate issued by CA with IAM Roles Anywhere as a trust anchor to establish trust between your public key infrastructure (PKI) and IAM Roles Anywhere.

A public-key infrastructure (PKI) is a comprehensive system that allows the creation, issuance, management, distribution, use, storage, and revocation of digital certificates. These certificates are used to verify the authenticity of various players involved in the data transfer process.

AWS offers the following two PKI services/tools to manage your certificate infrastructure.

1. AWS Certificate Manager (ACM)

2. AWS Private Certificate Authority (AWS Private CA)

We need two prerequisites to obtain temporary security credentials from IAM Roles Anywhere.

  • Private Certificate Authority
  • AWS signing helper

2. How to create Private Certificate Authority (PCA)/Private-Key Infrastructure (PKI)

There are two ways to create PCA/PKI:

  • Use AWS Certificate Manager 
  • Create own certificate authority using cfssl, vault PKI, OpenSSL.

Let’s create a PKI using cfssl to manage private CA.

cfssl can be installed based on the operating system (OS) you use.

For Mac OS, the command is as below:

brew install cfssl

For Linux OS, the command is as below:

sudo apt-get -y install golang-cfssl

Let’s create ca.json file to generate the certificate signing request as below.














         "O":"Custom CA",





Now let us run the following command to generate/create our CA.

cfssl gencert -initca ca.json | c fssljson -bare ca

3. Configure IAM Roles Anywhere

1. Create Trust Anchor

  • Open the AWS IAM console, navigate to Roles, and scroll down to the bottom, under the Roles Anywhere section, click Manage.
  • Click on Create a trust anchor button and type the anchor name
  • Select External certificate bundle.
  • Under the External certificate bundle, paste the CA certificate that we created previously. Get the contents of ca.pem file using the ‘less’ command.
  • Click Create trust anchor.

2. Create a Role That will Trust the IAM Roles Anywhere

Now we have to create an IAM role that trusts the IAM Roles Anywhere service and grants permissions to the clients. Here we will allow only those client certificates that have “OU=pravinlc” in their subject.

Go to IAM -> Roles -> Create Role -> Select Custom Trust Policy

Paste the following policy 


    "Version": "2012-10-17",

    "Statement": [


            "Effect": "Allow",

            "Principal": {

                "Service": "rolesanywhere.amazonaws.com"


            "Action": [





            "Condition": {

                "StringEquals": {

                    "aws:PrincipalTag/x509Subject/OU": "pravinlc"






Select managed policy “AmazonS3FullAccess” and select it.

Give a name for the role (I have named it ‘RoleAnyWhereS3FullAccess)’ and click Create Role.

3. Create a Profile under IAM Roles Anywhere

Now we will create a profile wherein we specify which IAM roles in our account we wish to allow clients to assume via temporary credentials.

Follow this: Roles Anywhere -> Create a profile and provide a name for the profile.

Under Roles -> select previously created role.

Till now we configured IAM Roles Anywhere, now let’s generate certificates for authentication.

Create a json file. I have created a json file named csr.json.


  "CN": "aws.pravinmishra.in",






         "O":"Custom CA",





Run the following command to generate Certificates for authentication.

cfssl gencert -ca ca.pem -ca-key ca-key.pem csr.json| cfssljson -bare aws.pravinmishra.in

Following are the public-key and private-key generated as below.

Now to use the client certificate to obtain temporary credentials, we have to use a credential helper tool called “AWS Signing Helper utility”.

Download the helper tool here as per your OS.

Now the helper file is available in your local system.

Now I need to change the directory permissions to use the helper file with the below command.

Use the following command to obtain temporary security credentials

./aws_signing_helper credential-process \

      --certificate /path/to/certificate \

      --private-key /path/to/private-key \

      --trust-anchor-arn arn:aws:rolesanywhere:region:account:trust-anchor/TA_ID \

      --profile-arn arn:aws:rolesanywhere:region:account:profile/PROFILE_ID \

      --role-arn arn:aws:iam::account:role/role-name-with-path

My command and its output is as below.

This output has the temporary AccessKeyId, SecretAccessKey, SessionToken, and Expiration details.

Now let us test the solution by exporting these credentials to our local machine as below.

Test if you are able to access S3 bucket contents via your local machine as below.

Well, now this is how we provide access to non-aws workloads from aws accounts.

Happy learning, keep being AWSfied!

Read our previous blog article on: AWS Explained: Everything You Need to Know About the Current and Future Landscape

Leave a Comment

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