AWS IAM Roles Anywhere and the Supply Chain

IAM Roles Anywhere was released in July 2022 as a way for workloads outside AWS to obtain temporary AWS credentials using X.509 certificates, without needing long-lived IAM user access keys. It has taken a few years to be adopted broadly, but it is now the authentication mechanism behind a surprising number of supply chain tools: third-party CI runners, on-premises build servers, container registries that push to ECR, signing tools that call KMS from outside AWS.

The good news is that Roles Anywhere replaces access keys, which were the worst authentication mechanism in AWS. The less good news is that the trust model is subtle, and the mistakes I have seen made during rollout often widen the attack surface rather than narrow it. This post walks through the threat model and the controls that matter for supply chain scenarios specifically.

What Roles Anywhere actually does

You configure a trust anchor in AWS IAM Roles Anywhere, which references a CA certificate you own (or an AWS Private CA). Any client that presents a certificate chained to that CA, along with a signed request, can call CreateSession against the Roles Anywhere endpoint and receive short-lived AWS credentials for a specified IAM role.

The flow: client holds a private key and a cert, signs a request to rolesanywhere.amazonaws.com/sessions, receives back a set of AWS credentials valid for up to twelve hours. The credentials are standard AWS temporary credentials. From that point on, the workload is indistinguishable from any other AWS role session.

The trust boundary is the CA. Anyone who can issue a certificate from your trust anchor CA can authenticate as any role that is configured to trust that anchor. This is a significant delegation.

Why this is a supply chain concern

Because the tools that end up holding Roles Anywhere certificates are often supply chain tools. Consider the common deployment patterns:

1. A GitHub-hosted runner in a self-managed runner group authenticates via Roles Anywhere to push artifacts to your ECR.
2. A Jenkins server on an EC2 instance in a different account authenticates via Roles Anywhere to deploy to production.
3. A container image signing service running on-premises authenticates via Roles Anywhere to call KMS Sign on your signing key.
4. A vulnerability scanner running on a colocated host authenticates via Roles Anywhere to read SBOM artifacts from an S3 bucket.

In each case, the certificate held by the external system is effectively a credential to do things inside AWS. If the external system is compromised, the attacker can authenticate to AWS. If the external system is itself a supply chain tool, this means a supply chain compromise has a direct path into your AWS environment.

The risk is qualitatively similar to having an IAM access key on the external system, but with two improvements and one subtle drawback.

Improvement one: the credential is a certificate with a private key, which is more protectable than a symmetric API key. You can use an HSM, a TPM, or a KMS-backed private key. You can set a certificate expiration. You can revoke via CRL or OCSP.

Improvement two: the session is time-limited. If an attacker extracts the certificate, they still have to repeatedly call Roles Anywhere, which leaves a CloudTrail trail and gives you a monitoring hook that long-lived access keys did not offer.

Drawback: the trust anchor is a CA, and a CA can issue an unlimited number of certificates. If your CA is compromised (or if the CA is operated by a third-party vendor whose controls are weaker than you think), the attacker can issue themselves a valid certificate and authenticate without ever touching the external system you were worried about. This is a new attack surface that access keys did not have.

CA strategy matters more than the role policies

The single most important decision in a Roles Anywhere deployment is what CA you trust as the anchor. The options:

AWS Private CA. Managed by AWS, key material in AWS KMS. Cost is meaningful (around four hundred dollars per month per subordinate CA). Operational overhead is low. Strong default.

Your own PKI, operated in-house. Full control. Requires that you actually operate PKI well, including HSM-backed root, offline root, CRL publishing, OCSP responders, automated certificate issuance and renewal. Most organizations do not operate PKI well enough for this to be safe. If you do not have a dedicated PKI team, do not pick this option.

A third-party CA operated by a vendor. Convenient, fast to set up, and the vendor becomes a trust anchor for AWS credentials in your environment. The vendor's access to your AWS environment is now proportional to the trust anchor's authority. Pick very carefully. I have seen organizations trust a certificate management SaaS as a Roles Anywhere anchor without realizing this meant the SaaS vendor could issue themselves valid certificates for any configured role.

My default recommendation: AWS Private CA with a root in a separate AWS account, operated by the security team, with subordinate CAs for each major class of external system. The cost is real but the trust boundaries are clear and auditable.

Scoping with attribute mapping

Roles Anywhere supports attributeMapping that pulls attributes from the X.509 certificate into AWS session tags, which can then be used in IAM policy conditions. This is the feature that lets you avoid having a separate role per external system.

The pattern: configure the attribute mapping to pull the certificate's CommonName into a session tag aws:PrincipalTag/HostId. The IAM role has a trust policy that accepts sessions from the Roles Anywhere principal and a permission policy that uses aws:PrincipalTag/HostId in resource conditions. For example, the role can read objects from arn:aws:s3:::artifacts/${aws:PrincipalTag/HostId}/* but not from other prefixes.

This collapses the "one role per host" explosion while preserving per-host scoping. Combined with careful certificate issuance (the CA only issues a certificate with CN=jenkins-prod-1 to a request from the jenkins-prod-1 machine, verified via some out-of-band identity check), this is a solid pattern for scoping external workload access.

Without attribute mapping, you either have one role for every external system (operationally painful) or one role with wide access and no per-host scoping (security anti-pattern). Attribute mapping is the middle path, and most Roles Anywhere deployments I have reviewed were not using it.

Revocation, practically

Roles Anywhere honors CRL and OCSP. You must publish a CRL (or run an OCSP responder) and configure the trust anchor to check it. The default trust anchor configuration does not require revocation checking, which means a revoked certificate continues to work until its natural expiration.

In practice, this means:

1. Publish a CRL to an S3 bucket with public read, refreshed hourly.
2. Configure the trust anchor's notificationSettings and enabled state to require CRL check.
3. When revoking, actually add the certificate to the CRL, do not just shut down the host.
4. Set certificate lifetimes short enough that natural expiration is a backup, not the primary revocation path. Ninety days or less is reasonable for most workloads.

I have seen deployments where revocation was "set up" in the sense that a CRL existed, but the trust anchor did not check it, and a compromised host's certificate remained valid for a year until it expired. Actually check.

CloudTrail visibility

Every CreateSession call to Roles Anywhere generates a CloudTrail event with the certificate's subject and serial number. This is the authentication event. Log it, alert on anomalies: a host authenticating from an unexpected source IP, a sudden spike in authentication frequency, a certificate authenticating after business hours for a workload that normally runs during business hours.

Pair the CreateSession events with the downstream IAM role session events. The trail from external host to specific AWS API call is traceable if you correlate session names. Set the session name to include the certificate serial number, and the session name propagates to every CloudTrail event the session generates.

How Safeguard Helps

Safeguard inventories every Roles Anywhere trust anchor, profile, and role in your AWS organization, and identifies anchors that reference external CAs, trust policies that do not require client certificate CRL check, and roles granting excessive permissions to external certificate holders. We correlate CreateSession events against downstream CloudTrail activity to surface unusual authentication patterns and certificate serial numbers authenticating from unexpected source IPs. For supply chain tools specifically, Safeguard ties the external system's identity back to the software artifacts it produces, so the chain from off-AWS build system to in-AWS deployed artifact is traceable end to end.