Understanding AWS Security Token Service (STS)
AWS Security Token Service (STS) allows you to obtain temporary credentials that can be used to access AWS resources.
These credentials are short-lived and typically valid for up to one hour, which improves security by avoiding long-term credentials.
Temporary credentials are commonly used for:
- role assumption
- federated users
- MFA authentication
AssumeRole
AssumeRole allows an identity to assume an IAM role and obtain temporary credentials.
This can be used for:
- users within the same AWS account
- cross-account access
For example, a user in one account may assume a role in another account to access resources securely.
AssumeRoleWithSAML
AssumeRoleWithSAML allows users who are authenticated through SAML identity providers to assume IAM roles.
This is commonly used for:
- enterprise identity systems
- single sign-on (SSO) setups
GetSessionToken
GetSessionToken is used to obtain temporary credentials when Multi-Factor Authentication (MFA) is required.
This API is commonly used when:
- a user must authenticate with MFA
- temporary credentials are required for programmatic access
Temporary credentials provided by STS are widely used in secure AWS architectures because they help reduce reliance on long-term credentials.
IAM Policy Evaluation Logic
When a request is made to access an AWS resource, AWS evaluates policies to determine whether the request should be allowed or denied.
Understanding how policies are evaluated is important when troubleshooting permission issues.
Explicit Deny
In AWS policy evaluation:
Explicit Deny always takes precedence.
If any policy explicitly denies an action, the request will be denied regardless of other permissions.
This rule is evaluated first.
Policy Evaluation Summary
When AWS evaluates permissions, the general flow is:
- Check for explicit deny
- Evaluate identity-based policies
- Evaluate resource-based policies
- Combine policies and determine final access
Understanding this process helps when diagnosing permission errors in AWS systems.
Dynamic IAM Policies and PassRole
Advanced IAM configurations often involve dynamic policies and role delegation.
These techniques allow permissions to be applied more flexibly across users and services.
Granting Permissions to Pass a Role
Some AWS services require permission to assume a role on behalf of the user.
For example, when configuring:
- Lambda functions
- ECS tasks
- other AWS services
You must allow the user to pass a role to the service.
This requires the permission:
iam:PassRole
Role Trust Relationships
In addition to the iam:PassRole permission, the role itself must define a trust relationship.
The trust policy specifies which AWS service is allowed to assume the role.
For example:
- Lambda service assuming a role
- EC2 instance assuming a role
Without the trust relationship, the service cannot assume the role even if the user has iam:PassRole.