- Регистрация
- 1 Мар 2015
- Сообщения
- 1,481
- Баллы
- 155
? Temporary credentials in AWS are powerful—but also widely misunderstood.
They allow developers and systems to access AWS resources without relying on long-lived access keys. But just because they expire doesn’t mean they’re safe by default.
In this post, I break down:
I’ve seen real-world setups where:
That defeats the whole point of ephemeral access.
?️ What You Should Be Doing
? Use least privilege roles
Scope your roles tightly and use IAM condition keys like aws:SourceIp.
? Shorten session durations
15–30 minutes is more than enough for most automation tasks.
? Log STS usage with CloudTrail
Every AssumeRole or GetSessionToken should be traceable and alertable.
? Require MFA where appropriate
Especially for sensitive role assumptions—break-glass or prod access.
? Automate responsibly
Don’t reuse temporary creds or store them insecurely in config files. Use the SDKs properly.
? Bonus: IAM Roles Anywhere
For non-AWS workloads (like on-prem apps), IAM Roles Anywhere lets you issue short-lived AWS credentials using signed certificates. It's a powerful addition for hybrid setups, but comes with its own set of guardrails.
? Want the full breakdown?
The original article goes deeper into:
?
Let me know:
How is your team managing AWS access today?
Still using long-term credentials… or have you moved fully to short-lived roles?
They allow developers and systems to access AWS resources without relying on long-lived access keys. But just because they expire doesn’t mean they’re safe by default.
In this post, I break down:
When and why to use temporary credentials- ? Where things go wrong (over-permissive roles, lazy session durations…)
- ? Best practices for keeping temp creds secure
- ? Advanced use cases like federation and IAM Roles Anywhere
I’ve seen real-world setups where:
- Temp credentials lasted 12 hours
- Were used with AdministratorAccess
- In CI/CD pipelines with no monitoring
That defeats the whole point of ephemeral access.
?️ What You Should Be Doing
? Use least privilege roles
Scope your roles tightly and use IAM condition keys like aws:SourceIp.
? Shorten session durations
15–30 minutes is more than enough for most automation tasks.
? Log STS usage with CloudTrail
Every AssumeRole or GetSessionToken should be traceable and alertable.
? Require MFA where appropriate
Especially for sensitive role assumptions—break-glass or prod access.
? Automate responsibly
Don’t reuse temporary creds or store them insecurely in config files. Use the SDKs properly.
? Bonus: IAM Roles Anywhere
For non-AWS workloads (like on-prem apps), IAM Roles Anywhere lets you issue short-lived AWS credentials using signed certificates. It's a powerful addition for hybrid setups, but comes with its own set of guardrails.
? Want the full breakdown?
The original article goes deeper into:
- Federation setups with Okta or AzureAD
- Example real-world misuses (and fixes)
- Credential rotation strategies
?
Let me know:
How is your team managing AWS access today?
Still using long-term credentials… or have you moved fully to short-lived roles?