AWS IAM Roles Anywhere: Attack Paths Through X.509 Certificate Abuse

AWS IAM Roles Anywhere was introduced in 2022 to solve a specific problem: how do workloads running outside AWS — on-premises servers, other cloud environments, edge devices, CI/CD runners — authenticate to AWS without long-lived access keys? The answer is X.509 certificates. A workload presents a certificate signed by a trusted Certificate Authority; AWS validates it against a registered trust anchor and grants temporary IAM credentials with the permissions of a configured profile.

The mechanism is sound. The implementation in many organisations is not. IAM Roles Anywhere introduces a new authentication path into AWS that many security teams haven’t fully modelled, and the attack surface is meaningfully different from standard IAM key management.

How IAM Roles Anywhere Works

The authentication flow has four components:

Trust Anchor — a Certificate Authority registered in IAM Roles Anywhere. This can be AWS Private CA, or any external CA whose certificate you import. When a workload presents a certificate signed by this CA, IAM Roles Anywhere considers the certificate trusted.

Profile — defines which IAM roles can be assumed and any session policy constraints. Multiple profiles can reference the same trust anchor with different role and permission configurations.

IAM Role — the role that workloads ultimately assume. The role’s trust policy must explicitly allow rolesanywhere.amazonaws.com as a principal.

Roles Anywhere Credential Helper — the open-source tool (aws_signing_helper) that performs the signing ceremony, calls the rolesanywhere:CreateSession API, and returns temporary AssumeRoleResponse credentials.

The credentials returned are standard temporary IAM credentials (AccessKeyId, SecretAccessKey, SessionToken) with a configurable session duration up to 12 hours.

Attack Path 1: Compromised CA Private Key

The most catastrophic scenario: an attacker gains access to the private key of a CA registered as a trust anchor. With the CA key, they can sign certificates for any identity and generate valid AWS credentials for any profile that references that trust anchor.

Why this happens: Organisations register their existing internal PKI CA as a trust anchor — the same CA used for TLS certificates, code signing, and VPN authentication. If that CA’s key is compromised (from a CA server breach, an HSM misconfiguration, or a key backup stored insecurely), the blast radius extends to AWS.

Detection: Monitor rolesanywhere:CreateSession CloudTrail events for certificate subjects that shouldn’t be generating AWS credentials. If your trust anchor is used for workload authentication, unexpected common names (CNs) or subject alternative names are a strong indicator.

# CloudTrail query for CreateSession events with unexpected certificate subjects
aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=EventName,AttributeValue=CreateSession \
  --query 'Events[*].{Time:EventTime,Subject:CloudTrailEvent}' \
  --output json | jq '.[] | select(.CloudTrailEvent | fromjson | .requestParameters.trustAnchorArn != null) | {Time, CN: (.CloudTrailEvent | fromjson | .requestParameters.subjectCommonName)}'

Hardening: Use a dedicated subordinate CA for IAM Roles Anywhere rather than your root or general-purpose intermediate CA. AWS Private CA subordinates cost $50/month and provide certificate issuance isolation — a compromise of credentials issued for one purpose doesn’t compromise the CA used for others.

Attack Path 2: Overpermissioned Profile Without Subject Condition

IAM Roles Anywhere profiles support condition keys that constrain which certificates can use the profile — based on the certificate’s common name, organisational unit, or other subject attributes. Most profiles are configured without these conditions, meaning any certificate signed by the trust anchor can assume any role referenced in the profile.

The consequence: A developer certificate, a test server certificate, or any certificate issued by the CA can generate credentials for production roles if the profile doesn’t restrict by subject.

What a correct profile condition looks like:

{
  "profileArn": "arn:aws:rolesanywhere:us-east-1:123456789012:profile/abc123",
  "roleArns": ["arn:aws:iam::123456789012:role/ProductionWorkloadRole"],
  "sessionPolicy": null,
  "managedPolicyArns": [],
  "requireInstanceProperties": false,
  "enabled": true,
  "subjectCriteria": {
    "allowedSubjectAlternativeNames": ["workload.prod.internal.example.com"]
  }
}

What most profiles look like: no subject criteria at all.

Hardening: Add subject conditions to every profile. The rolesanywhere:X509SubjectCommonName and rolesanywhere:X509SubjectOrganizationalUnit condition keys can be used in profile session policies and in IAM role trust policies to constrain which certificate identities can assume which roles.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "rolesanywhere.amazonaws.com"
      },
      "Action": ["sts:AssumeRole", "sts:SetSourceIdentity", "sts:TagSession"],
      "Condition": {
        "StringEquals": {
          "aws:PrincipalTag/x509Subject/CN": "prod-worker-01.internal.example.com"
        }
      }
    }
  ]
}

Attack Path 3: On-Premises Certificate Theft for AWS Lateral Movement

Workloads that use IAM Roles Anywhere store certificates and (critically) private keys on their filesystems. An attacker who compromises an on-premises server configured for Roles Anywhere access can extract the certificate and key, then generate AWS credentials from any machine with network access to the AWS endpoint.

Unlike IAM access keys, which trigger IAM access key compromise detection playbooks, a stolen X.509 certificate used to generate Roles Anywhere sessions may not trigger existing CSPM or SIEM rules tuned for key compromise.

Detection in CloudTrail: Look for CreateSession events from unexpected source IPs. If your production servers are in a known IP range, sessions generated from outside that range warrant investigation.

# Find CreateSession events from unexpected source IPs
aws logs filter-log-events \
  --log-group-name 'aws-cloudtrail-logs' \
  --filter-pattern '{ $.eventName = "CreateSession" && $.sourceIPAddress != "10.0.*" }' \
  --query 'events[*].message' | jq -r '.[] | fromjson | select(.eventName == "CreateSession") | {Time: .eventTime, IP: .sourceIPAddress, CN: .requestParameters.subjectCommonName}'

Hardening:

Store private keys in hardware security modules (HSMs) on-premises, not on filesystem
Use short-lived certificates (24-72 hours) and automate rotation via ACME or your PKI automation toolchain
Set RequireInstanceProperties: true on profiles where possible to bind sessions to specific machine characteristics

Attack Path 4: Excessive Profile Role Permissions

Profiles frequently reference roles with broad permissions inherited from the general IAM role design, rather than roles purpose-built for workload-specific minimum privilege.

Audit profile-to-role mappings:

# List all Roles Anywhere profiles and their associated role ARNs
aws rolesanywhere list-profiles --query 'profiles[*].{Name:name,ProfileArn:profileArn,RoleArns:roleArns[*]}' --output table

# For each role ARN, check its attached policies
aws iam list-attached-role-policies --role-name <role-name>
aws iam list-role-policies --role-name <role-name>

Any role referenced by a Roles Anywhere profile that has AdministratorAccess, PowerUserAccess, or *:* action permissions is a significant risk: a compromised certificate becomes a path to account-wide privilege.

Monitoring and Alerting

CloudTrail records all rolesanywhere:CreateSession events. Key fields to monitor:

Field	What to Alert On
`sourceIPAddress`	Any IP outside expected workload network ranges
`requestParameters.subjectCommonName`	Certificate subjects not matching expected workload identities
`requestParameters.profileArn`	Profiles that shouldn’t be actively used (development, decommissioned)
`responseElements.credentialSet.credentials.expiration`	Unusually long session durations

The CreateSession event is the chokepoint. Everything that uses IAM Roles Anywhere must pass through it, unlike assumed roles from EC2 instance metadata which don’t generate the same specific event type.

Hardening Summary

Control	Priority	Effort
Dedicated subordinate CA for Roles Anywhere	Critical	Medium
Subject conditions on all profiles	Critical	Low
Short-lived certificates with automated rotation	High	Medium
HSM-backed private keys for on-premises workloads	High	High
CloudTrail alerting on unexpected source IPs	High	Low
Role permissions reviewed specifically for Roles Anywhere use cases	High	Medium
`RequireInstanceProperties` where supported	Medium	Low

IAM Roles Anywhere is the right solution for hybrid workload authentication — it eliminates long-lived access keys. But it trades one attack surface for another. The CA becomes the root of trust for AWS access; the certificate lifecycle becomes a security control; and on-premises server compromise becomes a path to cloud credentials. Modelling these paths explicitly is the prerequisite for deploying Roles Anywhere securely.