IAM Roles Anywhere – now for everyone with Let's Encrypt

IAM Roles Anywhere -- now for everyone with Let's Encrypt

Speakers: Dhruv Ahuja

Conference: fwd:cloudsec North America 2025

YouTube: https://www.youtube.com/watch?v=M1hXUcBMf1Q

Overview

Dhruv Ahuja presents a clever, practical approach to using AWS IAM Roles Anywhere with free Let's Encrypt certificates as a PKI, eliminating the need for expensive private certificate authorities or full SPIFFE infrastructure when authenticating non-AWS workloads to AWS. The talk walks through the complete implementation: using Let's Encrypt's staging intermediate certificates as trust anchors, the ACME protocol with DNS-01 validation for certificate issuance, constraining access via X.509 subject common name conditions in IAM trust policies, and a novel private key theft detection mechanism inspired by nuclear weapons environmental sensing that uses TOTP (Time-based One-Time Passwords) derived from environment fingerprints as session names, enabling retrospective validation through CloudTrail.

Background

▶ Watch: Why you need IAM Roles Anywhere: on-prem, GPU providers, legacy CI/CD (0:30)

Organizations frequently need to authenticate non-AWS workloads to AWS -- on-premises servers, GPU providers, legacy CI/CD systems like Jenkins, or environments without OIDC support. The traditional approach is static AWS credentials (access key pairs), which are long-lived, difficult to rotate, and represent significant breach risk. IAM Roles Anywhere, released by AWS, allows workloads to assume IAM roles using X.509 certificates rather than static credentials, but it requires a PKI infrastructure that many organizations lack.

The barriers to adopting Roles Anywhere are significant: SPIFFE infrastructure may not exist, AWS Private CA costs approximately $400/month per CA (prohibitive for smaller organizations), many teams lack certificate authority experience, and certificate distribution to workloads remains an unsolved problem even with a PKI in place.

Ahuja's insight is that Let's Encrypt -- the free, automated certificate authority that issues certificates for web TLS -- can serve as the PKI for IAM Roles Anywhere, with some creative workarounds. The total cost of the solution is approximately $2 per year for a cheap domain name.

Key Findings

▶ Watch: Using staging certificates and ACME DNS-01 validation for issuance (5:30)

1. Let's Encrypt intermediate certificates work as Roles Anywhere trust anchors. While AWS documentation states that public CAs cannot be used as trust anchors (and this is true for root CAs), intermediate/subordinate CA certificates can be loaded into Roles Anywhere trust anchors successfully. Using Let's Encrypt's staging environment intermediate certificates (E5 and E6) is recommended since browser trust is unnecessary for this use case, and staging certificates have more generous rate limits.

1. Subject common name conditions prevent unauthorized use. The critical security control is a condition in the IAM role trust policy that restricts the certificate's subject common name to a specific domain name or its subdomains. Since Let's Encrypt validates domain ownership through DNS-01 challenges before issuing certificates, only workloads controlled by the domain owner can obtain valid certificates. This prevents any random Let's Encrypt certificate from authenticating to your Roles Anywhere configuration.

1. TOTP-based environment fingerprinting detects private key theft. Since private keys on disk cannot be truly protected without HSMs, Ahuja implements a detection-based approach inspired by Professor Ross Anderson's concept of environmental sensing from nuclear command and control systems. The workload computes a SHA-256 hash of an environmental invariant (NFD JSON, hardware identifiers, kernel parameters, or other static assets), uses this hash as a TOTP seed, and passes the resulting 6-digit code as the IAM Roles Anywhere session name. CloudTrail logs capture the session name, certificate subject, and event timestamp, allowing retrospective validation that the private key was used in the correct environment.

1. Revocation uses IAM deny policies rather than CRL. Let's Encrypt generates Certificate Revocation Lists only once per week, which is too slow for incident response. Instead, compromised certificates can be immediately blocked by adding a deny clause in the IAM trust policy matching the compromised certificate's subject common name.

Technical Deep Dive

▶ Watch: Subject common name condition in trust policy restricts access to your domain (8:30)

The implementation proceeds in several steps:

Trust Anchor Configuration: Download Let's Encrypt's staging intermediate CA certificates (E5 and E6), concatenate them, and upload as an external certificate bundle to a Roles Anywhere trust anchor. Create a Roles Anywhere profile and associate IAM roles with it.

Certificate Issuance via ACME: Purchase a cheap domain name and host it in Route 53 in a dedicated AWS account. Create an IAM user with a tightly scoped policy allowing only: GetChange, ListHostedZonesByName, ListResourceRecordSets, and CreateResourceRecordSet for TXT records only. Use the Lego ACME client (a Let's Encrypt client written in Go) with DNS-01 validation against the Let's Encrypt staging API. Two commands are needed: one for initial certificate issuance and one for weekly renewal. The result is a certificate and private key on the workload.

Role Trust Policy: The IAM role's trust policy specifies the Roles Anywhere trust anchor and includes a condition restricting aws:PrincipalTag/x509Subject/CN to the purchased domain and its subdomains. This ensures only certificates issued for that domain can assume the role.

Certificate Attribute Mapping: The Roles Anywhere profile includes certificate attribute mappings that decompose the X.509 subject into components available as session tags, enabling fine-grained authorization.

AWS Signing Helper: Workloads use the AWS-published open-source signing helper binary, passing five arguments: the private key path, certificate path, and ARNs for the trust anchor, profile, and role. A successful call returns temporary session credentials, exactly like sts:AssumeRole.

TOTP Environment Sensing: The workload computes the SHA-256 checksum of an environmental invariant (e.g., the NFD JSON file). The oathtool utility generates a TOTP code from this hash at the current timestamp. The 6-digit code is passed as the --role-session-name argument to the signing helper. The Roles Anywhere profile is configured to accept custom session names, and the trust policy requires the session name to be exactly 6 characters.

Retrospective Validation: A detection script (deployable as a Lambda function) reads CloudTrail events for Roles Anywhere sessions, extracts the certificate subject (to identify the environment), the event timestamp, and the role session name (the TOTP code). It recomputes the expected TOTP for that environment at that timestamp (and 30 seconds prior, to account for network latency). If the codes do not match, an alert fires. An attacker who steals the private key would need to also steal the exact environment fingerprint to generate valid TOTPs.

HSM Support: For environments with hardware security modules (such as YubiKeys), the private key can be generated and stored on the HSM. Certificate signing requests are generated using the HSM vendor's utilities, and the signing helper supports YubiKeys via the PKCS#11 interface.

Demo / Proof of Concept

▶ Watch: Environmental sensing: TOTP from environment fingerprint for key theft detection (11:30)

No live demo was shown, but Ahuja walked through the complete configuration including Lego commands, IAM policies, trust policy JSON, credential file configuration, and the TOTP detection script. He committed to publishing full systemd service files, timer files, and all JSON policy documents on his blog alongside the YouTube recording.

Defensive Implications

▶ Watch: Immediate revocation via IAM deny policies vs weekly CRL refresh (16:00)

This approach has several defensive advantages and considerations:

• Eliminates static AWS credentials for non-AWS workloads at a cost of approximately $2/year, making it accessible to organizations of any size.
• The TOTP environment fingerprinting mechanism provides a creative detection layer for private key compromise. While it cannot prevent key theft, it ensures that any use of a stolen key from a different environment will trigger an alert within one misstep.
• Session duration can be reduced to 15 minutes, limiting the blast radius of compromised sessions.
• Let's Encrypt is moving to 6-day certificate validity, which will further reduce the exposure window for compromised certificates.
• Monitor certificate transparency logs for the domain used in this configuration. If an attacker obtains a valid certificate for your domain, it will appear in CT logs.
• The static credentials for Route 53 DNS validation are the residual risk in this architecture. The IAM policy is tightly scoped (TXT records only, single hosted zone), but these credentials should still be protected and monitored.
• Immediate revocation via IAM deny policies bypasses the slow Let's Encrypt CRL refresh cycle (weekly).

Key Takeaways

• Let's Encrypt staging intermediate certificates can serve as trust anchors for AWS IAM Roles Anywhere, providing a free PKI alternative to AWS Private CA ($400/month) or full SPIFFE infrastructure.
• Subject common name conditions in IAM trust policies restrict authentication to certificates issued for a specific domain, preventing unauthorized Let's Encrypt certificates from gaining access.
• The TOTP-based environment fingerprinting technique, inspired by nuclear weapons environmental sensing, detects private key theft by validating that the key is used in the expected environment via CloudTrail session name analysis.
• Revocation is handled through IAM deny policies rather than CRLs, providing immediate effect versus Let's Encrypt's weekly CRL refresh.
• The total cost is approximately $2/year for a domain name, making IAM Roles Anywhere accessible to any organization regardless of size.
• Let's Encrypt's upcoming 6-day certificate validity will further strengthen this approach by forcing frequent renewal and reducing compromise windows.

About the Speaker(s)

Dhruv Ahuja is a security practitioner focused on AWS identity and access management. His background includes practical experience deploying IAM Roles Anywhere in environments needing to authenticate to AWS from non-AWS infrastructure, including GPU providers and legacy CI/CD systems. He draws on concepts from academic security research (citing Professor Ross Anderson's work on environmental sensing in nuclear command and control) and demonstrates a hands-on engineering approach to solving identity problems with minimal cost and infrastructure.