Taking Notice of AWS IAM Roles Anywhere

IAM Roles Anywhere may be a pivotal moment for security — the new service lets you enrich the arsenal of tools at your disposal to improve your AWS security posture.

Recently, AWS released IAM Roles Anywhere to extend the usage of IAM roles to hybrid (on-prem and AWS) environments that require access to AWS resources and don’t otherwise have an identity that can be federated to an AWS account.

Around the time the feature was released, we were creating a post on how to reduce the risk from IAM user access keys. The release of the IAM Roles Anywhere service caused us to change our approach to the topic, and revise the post’s structure and tone. This shift came about because we recognized that IAM Roles Anywhere may become a real game changer for identity management. We decided to take a moment to explain our revised point of view, why the service deserves attention and why you should look into it right now -- even if you don’t plan to adopt it any time soon.

What Is “IAM Roles Anywhere”?

IAM Roles Anywhere is a service that allows for non-federated identities outside AWS to assume IAM roles and use their permissions to access resources. It works by creating a trust anchor with a Certificate Authority, which can distribute certificates trusted by IAM Roles Anywhere. This trust can allow the identity to which the certificate is issued to sign requests to create a session for an IAM role. Following receipt of a request from such an identity, IAM Roles Anywhere can then communicate with the Security Token Service to create and send temporary credentials back to the requesting identity.

Thus, IAM Roles Anywhere allows authentication to AWS accounts of “local” (that is, outside AWS, usually for on-prem machines) identities. 

Until now, if you wanted to provide workloads with access to AWS resources and couldn’t (or weren’t inclined to) provide them with a federated identity (for example, using frameworks like spiffe-aws-assume-role), you probably had a different go-to solution. One such solution may have been to: 1) generate an IAM user with access keys, 2) provide the keys to the workload, and 3) let the workload use the keys to authenticate as the IAM user and use its permissions. As explored in our post, this long-lived AWS access mechanism is prone to errors and mishandling of the access keys (which are just two plaintext strings that, once leaked and until revoked, may provide anyone with the ability to authenticate as the IAM user). Therefore, the use of IAM users is discouraged unless absolutely necessary. Happily, IAM Roles Anywhere is a great replacement for them.

Taking IAM Roles Anywhere for a Test Drive

If you want to test out IAM Roles Anywhere you can do so in two fairly easy ways.

You can create a private CA (PCA) using the AWS Certificate Manager (ACM), request a private certificate and export it. You can then follow the AWS IAM Roles Anywhere tutorial or the AWS IAM Roles Anywhere demo for setting up IAM Roles Anywhere with a trust anchor and profile, and using the AWS signing helper tool to generate a signed request and obtain the temporary credentials.

Using IAM Roles Anywhere is very straight-forward, but you should consider two things:

• There’s a cost for setting up a CA with ACM PCA
• The signing helper tool requires access to the private key to perform the signing, which means you will need to store it locally on disk

Alternatively, you can use an open source tool published by serverless engineer Aidan Steele that lets you create a CA with a self-signed certificate using a KMS key and then use that CA to issue certificates for keys stored in your local SSH agent. As Aidan himself indicates, this is not a production-grade solution. However, if you’re looking for a cheap and easy way to run a proof-of-concept for IAM Roles Anywhere, this tool is definitely a good place to look.

As a side note, to work with Aidan’s open source tool, to configure IAM Roles Anywhere, you will need to configure AWS CLI with the proper permissions. Surprisingly, I had to engage in some trial and error to find the specific permissions necessary to complete the setup. To save you time – and, in the name of least privilege, help you avoid granting “iam:*” and/or “rolesanywhere:*” – here’s theIAM policyI eventually used:

{
   "Version": "2012-10-17",
   "Statement": [
       {
           "Sid": "VisualEditor0",
           "Effect": "Allow",
           "Action": [
               "iam:GetRole",
               "iam:PassRole",
               "kms:GetPublicKey",
               "kms:DescribeKey",
               "kms:Sign"
           ],
           "Resource": [
               "<ROLE_TO_BE_USED_IN_PROFILE_ARN>",
               "<ASYNC_KMS_USED_FOR_SELF_SIGNED_CA_CERT_ARN>"
           ]
       },
       {
           "Sid": "VisualEditor1",
           "Effect": "Allow",
           "Action": [
               "rolesanywhere:CreateTrustAnchor",
               "rolesanywhere:CreateProfile",
               "rolesanywhere:TagResource"
           ],
           "Resource": "*"
       }
   ]
}

So… What’s the Big Deal?

On the surface you may say that IAM Roles Anywhere, which involves use of private keys rather than access keys, is just a marginal improvement for a specific use case of securing identities. Some may point out that you still have to guard the CA and private keys used to sign the authentication requests, just as you had to guard the access keys from an IAM user. This is true.

However, as mentioned before, this feature may in fact be a pivotal moment for IAM security.

First of all, it’s important to remember that private keys have very secure hardware storage mechanisms such as TPMs, which allow them to be safely stored and used without extraction/retrieval in plaintext form. It’s also safe to say that R&D and IT professionals everywhere are more conscious of supply chain best practices for private keys — which are usually far superior security-wise to any kind of transmission of plaintext access keys — than of those for plaintext credentials. So private keys are far less error prone than static access keys. CAs are of course significant anchors of security which are hopefully also well secured.

But there’s more to it than that.

Over the years, for many of the mainstream use cases in which IAM users are utilized, other methods have – for security and operational concerns – been adopted as best practices. Ironically, a great example of such a use case is providing access (including CLI) to human users. The best practice for providing such access has long been consideredfederation to an identity providerand, more recently, usingAWS IAM Identity Center(formerly AWS SSO). The same is true of course for the use case of granting access to third parties, for whichIAM roles with an external IDis the widely known best practice.

These mechanisms leverage IAM roles to create and use temporary credentials rather than long-term static credentials. It’s obvious why such approaches are more secure.

As Ben Kehoepoints out, the situation of an on-prem workload with no other identity you can use for federation is considered the “last bastion” for using long-term static credentials. And IAM Roles Anywhere seems to have the potential to become the “enabler” for retiring them. When IAM Roles Anywhere gains enough traction, and AWS or real-world users publish more implementation examples, organizations should have an easier time using the service with confidence. IAM Roles Anywhere could then very well be a game changer in making the high-risk practice of static permanent credentials in the form of access keys scarce. The existence of IAM users will be so rare, security professionals will be able to be – as always recommended – more vigilant and bolder about ridding their environments of IAM access keys, allowing them only after considerable scrutiny and when truly warranted.

In fact, as Brigid Johnson, a senior manager with AWS Identity, tweeted in a recent thread on IAM best practices:

So, even from AWS’s perspective, TODAY may already be the time for us to stop using IAM users nearly altogether and single out only the rare cases in which they are absolutely necessary. IAM Roles Anywhere is definitely a major step in getting there.

Promoting adoption of IAM Roles Anywhere for your organization’s workloads may take time for political and/or technical reasons. But get ahead of the curve by becoming familiar with the service now, and even building and sharing implementations around it.