Identity and permissions · Chapter 2 of 2
How AWS manages temporary access
An access key committed to a repository is a security breach waiting to happen, but learning to use temporary credentials through roles completely removes this risk.
FoundationsBuilds the idea from nothing. No prior AWS assumed.
Why temporary identity beats static keys
Why are roles preferred over static credentials in cloud environments?
An application principal sends an sts:AssumeRole request to AWS STS to get temporary security credentials.
- 01
The problem with static keys
A static access key is a username and password designed for code. Because it is static, it stays valid until someone explicitly deletes it. If an engineer commits a key to a public repository, or if it is cached in a local build log, anyone who finds it inherits those permissions indefinitely.
- 02
Enter the IAM role
An IAM role is an identity with no permanent credentials. Instead of holding a password, a role defines who is authorised to assume it. When a client assumes a role, AWS issues temporary security credentials that expire automatically after a short window.
- 03
The two policies that shape a role
Every role requires two distinct policy documents to function. The trust policy determines which external entities, like an EC2 instance or a human user, are permitted to assume the role. The permission policy determines what actions the caller can perform once they have successfully assumed it.
- 04
No key storage required
When an application runs on AWS compute services like Lambda, the runtime environment assumes the role automatically. The temporary credentials are placed in the environment variables where the SDK finds them. There is no config file to manage and no credential to rotate manually.
Check yourself
What is the primary security advantage of using an IAM role instead of an IAM user?
Under the hoodThe same thing from underneath: limits, failure modes, numbers.
How the Security Token Service protects credentials
What happens behind the scenes when a client assumes a role?
An application principal sends an sts:AssumeRole request to AWS STS to get temporary security credentials.
- 01
The role of the Security Token Service
When a principal calls `sts:AssumeRole`, the request is processed by the AWS Security Token Service. STS validates the credentials of the caller and checks the trust policy of the target role. If the trust policy allows the caller, STS returns three items: an access key, a secret key, and a session token.
- 02
Session duration and automatic expiry
Every temporary session has an expiration time defined at the moment of the call. If a client attempts to use expired credentials, the API call returns an `ExpiredToken` error. The calling application must request a new session from STS to resume operations.
- 03
The constraints of role chaining
Role chaining occurs when a client assumes one role and then uses those credentials to assume another. While this can help isolate environments, AWS limits the chain duration. When chaining roles, the session duration is fixed to a short window and cannot be extended.
The numbers
- Default session duration
- 1 hourApplies to roles assumed via the CLI or SDK.
- Maximum session duration
- 12 hoursCan be configured on the role properties.
- Minimum session duration
- 15 minutesUseful for short-lived worker processes.
- Role chaining duration limit
- 1 hourAWS restricts chained sessions to one hour regardless of the maximum role setting.
Check yourself
An application assumes Role A, and then immediately uses those credentials to assume Role B. What is the maximum duration the session for Role B can have?
Official references & further reading
These lessons simplify selected behaviors for learning. Verify current service limits, Region support and production requirements with the official references. Experiments describe their own assumptions.
Report an error or suggest a clearer explanation →