5.1.2. Temporary Credentials and Token Mechanisms

First Principle: Temporary credentials expire automatically, eliminating the risk of persistent credential exposure. Every workload and every human access should use temporary credentials — long-term keys are a security liability.

AWS Security Token Service (STS):

• Issues temporary credentials (access key + secret key + session token) with configurable expiration
• Used behind the scenes by: IAM roles, Identity Center, Cognito, cross-account access
• Key API actions:
  • AssumeRole — Get credentials for an IAM role (most common)
  • AssumeRoleWithSAML — Get credentials using SAML assertion from IdP
  • AssumeRoleWithWebIdentity — Get credentials using web identity token (mobile/web apps)
  • GetSessionToken — Get temp credentials for IAM user with MFA
• Endpoints: the global endpoint (sts.amazonaws.com) historically ran only in us-east-1. It is now served locally in default-enabled Regions when the Amazon DNS server resolves it, but requests from opt-in Regions or through other DNS resolvers still go to us-east-1 — AWS recommends Regional STS endpoints for latency and resiliency

S3 Presigned URLs:

• Generate time-limited URLs that grant temporary access to specific S3 objects
• Include the signer's credentials in the URL — permissions match the signer's permissions
• Expiration configurable (up to 7 days when signed with an IAM user's long-term keys); a URL signed with temporary credentials (e.g., a role session) stops working when those credentials expire, even if a longer expiration was requested
• Use case: grant temporary download access to private S3 objects without sharing credentials

IAM Roles Anywhere (new in C03):

• Enables on-premises workloads to assume IAM roles using X.509 certificates
• No long-term access keys needed for hybrid environments
• Trust anchor: certificate authority (AWS Private CA or external CA) that issues certificates
• Profile: maps certificates to IAM roles with session policies
• Compromised CA: disable or delete its trust anchor so no certificate it issued can obtain credentials; revoke individual certificates by importing a CRL
• Use case: on-premises servers, IoT devices, and partner systems that need AWS API access

⚠️ Exam Trap: IAM Roles Anywhere uses X.509 certificates (not SAML or OIDC) for on-premises workloads. If a question describes on-premises servers needing AWS access without long-term keys, Roles Anywhere is the answer.

Scenario: A hybrid architecture has on-premises batch processing servers that need to write to S3. Currently, they use long-term access keys stored in configuration files. You migrate to IAM Roles Anywhere: issue X.509 certificates from AWS Private CA, define a trust anchor and profile, and the servers assume IAM roles for temporary credentials.

Reflection Question: Why does IAM Roles Anywhere specifically solve the long-term credential problem for on-premises workloads, and how does it differ from federation?