AWS Security Token Service (STS) Overview

AWS STS is a pivotal security service within AWS, providing a mechanism for granting limited and temporary access to AWS resources. Below are the key aspects and functionalities of AWS STS:

• Temporary Security Credentials: STS allows issuing temporary credentials (tech tokens) that can be valid for up to one hour or more. These credentials must be refreshed upon expiration.
• AssumeRole API Call: This is used to assume a role within your own AWS account for enhanced security, allowing credentials to be invalidated after a certain period. It can also be used in a cross-account access scenario to perform actions in a target account.
• AssumeRoleWithSAML: This function is for users logged in with SAML (Security Assertion Markup Language), allowing the extension of SAML authentication to obtain credentials from STS. Configuration of STS to exchange and verify SAML tokens is required.
• AssumeRoleWithWebIdentity: Aimed at users authenticated through identity providers (e.g., Facebook, Google), this feature exchanges web identity tokens for STS credentials. AWS recommends using Amazon Cognito for newer implementations due to the deprecation of this API call.
• GetSessionToken: This is particularly useful for MFA (Multi-Factor Authentication) scenarios. It provides a way to obtain credentials after logging in with MFA.

Implementation Steps for Using STS

The process for utilizing STS to assume a role involves several steps:

1. Define an IAM Role: This role is created within your account or for cross-account access, specifying which principals can access this role.
2. Retrieve Credentials via STS: Use the STS service to obtain temporary credentials that allow impersonation of the IAM role you have access to.
3. Assume Role: Authorized users or entities can assume the defined role through the AssumeRole API, receiving temporary credentials for access.

Cross-Account Access with STS

Cross-account access is a powerful feature of STS, enabling resources in one account to be accessed by users in another. Here’s a simplified procedure:

1. Create an IAM Role in the Production Account: This role should have permissions to access specific resources (e.g., an S3 bucket).
2. Grant Permissions in the Dev Account: Permissions are granted to an IAM group in the development account to assume the defined IAM role in the production account.
3. Assume the Role: Upon assuming the role, STS provides role credentials that allow access to the target account's resources.
4. Access Control: The IAM role in the production account must authorize the development account to assume it. If an IAM group (e.g., testers) is not authorized, they cannot access the production resources.

Conclusion