Temporary credentials and STS

Exam tasks: 4.1 (Skills 4.1.2 mechanisms that issue temporary credentials, 4.1.3 troubleshooting authentication with CloudTrail), 4.2 (Skills 4.2.1 role trust policies and IAM Roles Anywhere, 4.2.3 session policies)

The decision: who (or what) is asking for credentials, what have they already proved, and which STS call turns that proof into the shortest-lived, narrowest session that works?

Which STS APICopy Anchor Link

• Every session is at least 15 minutes. Set the role's maximum session duration from 1 to 12 hours.
• Role chaining (a role session assuming another role) is limited to 1 hour, whatever the role's maximum.
• sts:GetCallerIdentity needs no permission and always works. It's the first call when debugging "who am I?"
• Credentials already issued stay valid until they expire, even if you change the role. See revoking sessions.

Trust policies and the confused deputyCopy Anchor Link

A role has two policies: the trust policy (who may assume it) and the permissions policies (what the session may do). Both must be right.

• Third party assumes your role: require an sts:ExternalId the vendor generates per customer. Without it, another customer of the same vendor could trick the vendor into using your role. That's the confused deputy.
• AWS service acts on your resource: in resource policies, condition on aws:SourceArn or aws:SourceAccount so the service only acts for your resource, not someone else's.
• OIDC: never trust a provider without conditions on aud and sub. A GitHub trust with no sub condition lets any repository on GitHub assume the role.

{
  "Effect": "Allow",
  "Principal": { "AWS": "arn:aws:iam::210987654321:root" },
  "Action": "sts:AssumeRole",
  "Condition": { "StringEquals": { "sts:ExternalId": "fernhill-7Q2K9" } }
}

Shaping a sessionCopy Anchor Link

IAM Roles AnywhereCopy Anchor Link

• For workloads outside AWS (on-prem servers, other clouds, edge devices) that hold an X.509 certificate.
• Trust anchor: your CA, either AWS Private CA or an uploaded external CA bundle. Profile: which roles can be assumed and an optional session policy. Role: trusts rolesanywhere.amazonaws.com, ideally with aws:SourceArn pinned to the trust anchor and conditions on certificate attributes.
• The credential helper signs CreateSession with the private key and returns standard temporary credentials.
• Import a CRL to revoke certificates. Protect the private key, ideally in a TPM or HSM.

Presigned URLsCopy Anchor Link

• S3 presigned URLs let someone without AWS credentials GET or PUT one object until expiry.
• The URL carries the signer's permissions. If those credentials are temporary, the URL dies when they expire, whatever expiry you set. Maximum 7 days with SigV4 and long-term keys.
• Restrict their use with bucket policy conditions such as s3:signatureAge or aws:SourceIp.

Revoking and hygieneCopy Anchor Link

• Revoke active role sessions: "Revoke active sessions" on the role adds an inline deny with aws:TokenIssueTime earlier than now. Fixing the policy alone doesn't end sessions already issued. See compromised credentials.
• Access keys: at most 2 per user, so you can rotate: create, switch, deactivate, delete. Find old or unused keys with the credential report (all users, generated at most every 4 hours, as CSV) and GetAccessKeyLastUsed.
• Prefer roles for EC2 (instance profiles), Lambda and ECS tasks. Their credentials rotate automatically.

Root user protectionCopy Anchor Link

• Enable centralized root access in the IAM console for the organization. Then you can delete root credentials (password, keys, MFA, certificates) in member accounts, and new accounts have none.
• Root-only tasks run from the management account or IAM delegated admin with sts:AssumeRoot, scoped by an AWS managed task policy: audit root credentials, delete root credentials, allow password recovery, unlock an S3 bucket policy that denies everyone, unlock an SQS queue policy that denies everyone.
• For the management account itself (and standalone accounts): MFA on root, no root access keys, alert on root sign-in with EventBridge.
• Add an SCP that denies actions by arn:aws:iam::*:root in member accounts as a second layer.

ScenariosCopy Anchor Link

Further readingCopy Anchor Link

• Compare AWS STS credentials
• The confused deputy problem
• Centrally manage root access for member accounts
• What is IAM Roles Anywhere?