Roles, temporary credentials, and SigV4
1. Roles, temporary credentials, and SigV4
We've settled which identity AWS checks and what a policy lets it do. Now let's see how your code becomes that identity without storing a key.2. The key that outlives the task
Almost every insecure setup begins with the same excuse: we just needed the script to work. So a key gets created, dropped into a config file, done. The real problem isn't that it might leak, it's that it will never be touched again. Never rotated, never revoked, never expiring.3. The key that outlives the task
It gets copied, backed up, and logged. Eighteen months later every copy still works, like a spare key handed to a contractor and never taken back. Nobody planned that; it's what happens when nothing expires.4. Credentials that expire on their own
The fix is to make expiry the default. Security Token Service, or STS, hands out temporary credentials: your application assumes a role, and STS returns credentials with an expiry attached, one hour by default.5. Credentials that expire on their own
You can tell the two apart on sight. A long-lived key ID starts with AKIA and never expires. Temporary ones from STS start with ASIA and carry a session token.6. Credentials that expire on their own
Your application makes its calls normally. An hour later the session runs out and those same credentials stop working, like a hotel keycard at checkout. Access that ends by itself.7. How your code finds them
So how does your code get hold of those credentials? It doesn't go looking; the AWS SDK, the library in your code, does. It walks a fixed list, the credential provider chain, and takes the first match.8. How your code finds them
A key passed directly into your code is checked first and always wins, so the chain never runs. Delete it, and the chain searches: on AWS with a role attached, it finds credentials on its own.9. The chain, link by link
The chain is an order, not a preference. The SDK takes the first link holding a credential and stops. A key you stored sits above the role, so it wins every time. That is why deleting one stored key changes which credential your function uses.10. Proving identity from outside AWS
The chain only finds credentials by itself on AWS. But a build job runs outside AWS on a CI platform, so no role gets attached and a key ends up in repository secrets.11. Proving identity from outside AWS
This is where identity tokens come in. Rather than store a key, the platform, GitHub or GitLab, vouches for the job. It signs a short-lived identity token, called OIDC, naming the repository and the workflow.12. A rule instead of a stored key
STS trades the OIDC token for those same expiring credentials through AssumeRoleWithWebIdentity: AssumeRole, with an outside token as the proof.13. A rule instead of a stored key
Each fact inside that token is a claim. It works because the role's trust policy, the rule for who may assume it, already names two of them. The issuer says which platform vouched for the job, and every repository there shares it, so the trust policy pins the repository too. Nothing gets stored in the repository, so nothing can leak.14. Every request is signed
Underneath, every one of these calls is signed using Signature Version 4, or SigV4. It proves which credential made the call and that nothing changed in transit. The CLI and SDK do it automatically, so you'll rarely sign one by hand.15. A signature you can hand over
So far, every pattern has been temporary credentials your code holds. But sometimes only one person, one file, needs access, and your code isn't involved.16. A signature you can hand over
A pre-signed URL is that signature, pre-calculated and handed over: one object, one action, and an expiry you choose when you sign it. It is a valet ticket: whoever holds it fetches the one car, without your keys. Next time you paste a key into a config file, ask when it stops working.17. Let's practice!
Now it's time to practice with roles and temporary credentials.Create Your Free Account
or
By continuing, you accept our Terms of Use, our Privacy Policy and that your data is stored in the USA.