IAM Roles, AWS STS & Temporary Credentials

A role is an assumable identity, not a person

An IAM role is an AWS identity with permissions but without the same permanently associated credentials model as an IAM user. A trusted principal assumes the role and receives temporary security credentials for a role session. Roles are therefore suited to applications running on AWS, AWS services that need to act on a customer's behalf, cross-account access, and federated users who should not receive long-lived IAM access keys.

Two policy questions surround a role. Its trust policy is a resource-based policy that defines which principals may assume the role and under which conditions. Its permissions policies define what an authorized role session may do after assumption. In cross-account access, the trusting account's role trust and the caller's permission to invoke the relevant STS operation both matter. Conditions such as an external ID can further protect delegated third-party access from confused-deputy scenarios.

AWS STS turns authorization into a time-bounded session

AWS Security Token Service (AWS STS) operations such as AssumeRole return temporary credentials containing an access key ID, secret access key, and session token. SDKs and AWS compute integrations can obtain and refresh these credentials without placing a long-lived secret in application source code. The credentials expire, which reduces the window of usefulness if they are exposed, although short lifetime is not a substitute for least privilege or detection.

The caller can sometimes supply a requested session duration, session tags, source identity, or a session policy depending on the operation and configuration. Session policies restrict a session; they cannot expand it beyond the permissions available to the role. Source identity and session context can make CloudTrail activity easier to connect back to the original human or workload, while session tags support attribute-based authorization patterns when the trust and permission policies allow them.

Temporary credentials are the default design for workloads

AWS compute services can deliver role credentials to workloads through service integrations such as instance profiles or execution/task roles and automatically rotate the underlying temporary credentials. Application code should use the standard SDK credential provider chain rather than copying credentials from metadata endpoints into configuration files. This separates application deployment from credential lifecycle and greatly reduces the need to create long-term IAM user access keys for machines.

Role chaining occurs when credentials from one assumed role session are used to assume another role. AWS imposes a stricter session-duration limit on chained role sessions than on many directly assumed roles. Because role and STS limits can evolve, production designs should read the current IAM and STS documentation rather than hard-code assumptions about maximum session lifetime.

• Prefer service-provided role credentials for workloads running on AWS.
• Do not store STS session tokens or long-term access keys in application source control.
• Use trust-policy conditions to constrain who can assume sensitive roles.
• Use CloudTrail plus source identity/session context when traceability across assumed roles matters.