Roles Anywhere and presigned URLs

Lesson 3 of 4 in Temporary Credentials.

Two mechanisms for handing out temporary access at the edge of AWS, both named explicitly in the exam guide, and both frequently misremembered.

IAM Roles Anywhere solves the oldest credential problem there is: a server in your own data centre needs to call AWS. The traditional answer was an IAM user with access keys baked into a config file — long-lived, rarely rotated, and copied into the next build. Roles Anywhere replaces the key with an X.509 certificate your PKI already issues, and turns it into a normal STS session.

Three objects, all exam-nameable:

1. A trust anchor — the certificate authority AWS will trust. Either an AWS Private CA in your account or an external CA whose certificate you upload.
2. A profile — which IAM roles certificates from that anchor may assume, plus an optional session policy to narrow them.
3. A role whose trust policy trusts the rolesanywhere.amazonaws.com service principal for sts:AssumeRole, sts:TagSession, and sts:SetSourceIdentity, with aws:SourceArn pinned to the trust anchor.

The workload runs a signing helper that presents its certificate to CreateSession and receives ordinary temporary credentials.

S3 presigned URLs are the other temporary-credential mechanism the exam guide names, and the one with the most dangerous misconception attached to it.

Mechanically: the signer computes a SigV4 signature over a specific request — method, bucket, key, expiry — using their own credentials, and embeds it in the URL's query string. S3 verifies the signature and then authorizes the request as the signer. There is no further authentication: possession of the URL is the credential.

Two consequences decide questions.

A presigned URL can never grant more than the signer has. Presigning a GetObject you are not permitted to perform produces a URL that fails when used. Presigning with a role that was later denied the action produces a URL that stops working. This is why "share one object with an external auditor for an hour, without changing the bucket policy" is the presigned-URL reflex — you are lending a slice of your own access, not adding a grant to the bucket.

And it is a bearer token. Anyone who obtains the link — forwarded email, chat log, browser history, proxy log — has that access until expiry. There is no revocation of the URL itself; what you can revoke is the credential that signed it.

Lifetimes are where the details live:

• Signed with IAM user credentials: up to 7 days.
• Signed with temporary credentials (a role, an instance profile, an STS session): the URL expires when those credentials expire, even if you asked for longer. An EC2 instance-profile signature typically means a few hours.
• Generated from the console: 1 minute to 12 hours.
• Deleting, revoking, or deactivating the signing credential invalidates the URL immediately.

Presigned POST does the same job for browser uploads: instead of a URL, the server returns a policy document and signature that the browser posts as form fields, letting you constrain key prefix, content type, and size limits — the safer pattern when the client chooses the object name.

Key terms: IAM Roles Anywhere, Trust anchor (Roles Anywhere), S3 presigned URL

Interactive checkpoint quiz (2 questions) — open this page in a browser to take it.