AWS recently announced a new revolutionary Identity and Access Management (IAM) feature - IAM Roles Anywhere. This feature allows workloads (or any certificate holding entity, for that matter) outside the AWS account (on-prem or in other clouds), to assume a role (obtain temporary credentials for a role) in your AWS account and access AWS resources. While this feature presents a significant improvement in management of external access to AWS resources, it also presents security challenges; and unless done correctly; could potentially reduce the governance and manageability of your workload's identities.
Prior to this feature, an on-premises server could access an S3 bucket in an AWS account, for example, by creating an IAM user in the AWS account, creating access keys for that IAM user, and placing the keys on the on-premises server. It is considered bad practice to use access keys to identify workloads for a variety of reasons, including:
In comes Roles Anywhere
To simplify; this feature relies on a CA (Certificate Authority) that issues certificates to your workloads confirming they are recognized by the CA. Inside AWS, you create a Trust Anchor, which is basically telling AWS “this is my CA, which I trust to authenticate my workloads.” Additionally, you create “profiles” that are collections of roles that can be assumed, once you are trusted by this trust anchor.
When a workload wants to access an AWS resource, let's say, the S3 bucket above, it presents AWS with its certificate signed by the CA and signs the request with its private key. If the certificate is valid, AWS will return the temporary credentials for that role to the calling workload.
IAM Roles Anywhere (Courtesy AWS Identity):
Any role that would be assumed by workloads using Roles Anywhere should trust the “rolesanywhere” service by adding the rolesanywhere service to its trust policy. The following trust policy example presents the minimum requirement in a role’s trust policy, for the role to partake in Roles Anywhere:
Workloads can be distinguished by the Organizational Unit (OU) and Subject Common Name (CN) in the certificate. Both, the CN and OU are available in the aws:principalTag key to be used as a condition in the role's trust policy.
In the example above, if this role should only be assumed by a workload named “pipeline.prod” - the CA would issue the workload a certificate with CN = “pipeline.prod” and the role’s trust policy should include the following condition:
One of the biggest challenges in managing IAM in the cloud is answering the question - who can access my cloud? Put differently: Where are my identities?
In any cloud environment, the identities are a mix of IAM users, workloads, externally assumed roles, and federated identities. While the need to eliminate usage of IAM users and access keys is clear, the goal should be to reduce complexity, rather than increasing it.
The combination of CA and condition keys in rolesanywhere renders them as a cloud identity store, where your identities hide in the CN as defined by the CA and enforced by your condition keys. Imagine a cloud security admin trying to figure out, “who can assume this role from the internet?” going through multiple complex JSON objects of trust policies and chasing the CA config to map the workload assuming the role and accessing the data.
To put it in another way, condition keys are hardly where you want to manage your identities that can access your account from the internet.
In terms of blast radius management, once rolesanywhere is used in the environment, a compromised CA means a compromised AWS environment, which is non-trivial.
In addition, some non-trivial configuration gaps one should be aware of, when deploying this service: