STS & AssumeRole
AWS STS (Security Token Service) issues temporary security credentials (access key, secret key, session token) that expire after 15 minutes to 12 hours. AssumeRole is the primary STS action for cross-account access and service delegation.
STS is a visitor badge system — you get a temporary badge (credentials) that expires at end of day. AssumeRole is signing in at the front desk; IRSA is a worker badge that only grants access to specific rooms (pods to AWS services).
Use cases: EC2 instance assumes a role to access S3 (via instance profile), Lambda assumes its execution role, a developer assumes a production role for a limited time, a CI/CD pipeline in Account A assumes a deployment role in Account B. The trust policy on the role defines who can assume it (the principal). The permission policy defines what they can do. Chaining: you can call AssumeRole to get credentials, then assume another role (with max 1-hour session).
STS regional endpoints reduce latency and are more available than the global endpoint. AssumeRoleWithWebIdentity is used by OIDC-compatible identity providers (GitHub Actions, EKS service accounts via IRSA — IAM Roles for Service Accounts). IRSA is the preferred method for pod-level IAM in EKS, replacing node-level IAM which gives all pods the same permissions. External ID prevents confused deputy attacks in cross-account role assumptions by third parties — the third party provides a secret External ID that only they know, preventing other AWS accounts from tricking them into assuming the role.
STS issues short-lived credentials that expire, eliminating the risk of leaked long-term keys. I use AssumeRole for cross-account deployments — CI/CD in a tooling account assumes deployment roles in each environment account. For EKS, I use IRSA (IAM Roles for Service Accounts) for pod-level IAM instead of node instance profiles. External ID is required when a third-party SaaS needs to assume a role in your account — it prevents confused deputy attacks.
Confused deputy problem: without External ID, any AWS account could potentially trick a third-party service into assuming your role because the third party has broad AssumeRole permissions. External ID ensures only the correct third party can assume the role.