AWS Security Token Service (STS) 是一个非常强大且灵活的工具，熟练掌握它的使用技巧能极大地提升你的 AWS 环境的安全性、灵活性和可管理性。
这里为你整理了一份从基础到进阶的 STS 使用技巧，涵盖了核心概念、最佳实践和常见场景。
从根源理解 STS 的三大核心功能
STS 的所有技巧都围绕它的三个核心 API 展开，理解它们是掌握 STS 的第一步。
-
AssumeRole (扮演角色)
- 是什么：这是 STS 最常用、最强大的功能，允许一个主体（用户、角色或应用程序）临时“扮演”另一个 IAM 角色,并获得该角色的权限。
- 核心技巧：权限的临时授予和隔离，你不需要给用户或服务永久的、高权限的 IAM 权限，而是创建一个具有特定高权限的角色，让用户在需要时去临时扮演它，用完即失效,非常安全。
- 典型场景：
- 开发人员需要临时访问生产环境的 S3 存储桶进行排错。
- 一个 EC2 实例需要临时写入另一个 AWS 账户的 DynamoDB 表。
- CI/CD 流水线需要部署资源到特定的 AWS 环境。
-
GetFederationToken (获取联邦令牌)
- 是什么：为已通过身份验证的 IAM 用户（非根用户）提供一个临期的、自定义权限的访问令牌。
- 核心技巧：为特定用户会话创建临时权限，与
AssumeRole不同，它不依赖于 IAM 角色，而是直接作用于用户,可以精细控制这个令牌的权限和有效期。 - 典型场景：
- 允许一个第三方开发者通过你的 AWS 账户进行一次特定的数据查询，并限制其只能访问某个 S3 路径和只能读。
- 创建一个自定义的登录门户，用户登录后获得一个临时令牌来访问 AWS 资源。
-
GetSessionToken (获取会话令牌)
- 是什么：为 IAM 用户（通常是账户根用户）生成一个临期的访问密钥（Access Key ID, Secret Access Key, Session Token）。
- 核心技巧：为根用户启用 MFA 后的安全登录方式，这是 STS 最经典的应用，当你需要以根用户身份执行高危操作时，不应使用永久的根密钥，而应先通过 MFA 验证，然后用 STS 获取一个短期有效的会话令牌进行操作。
- 典型场景：
- 账户管理员需要手动执行一次账户级别的删除操作，必须启用 MFA 才能获取临时凭证。
- 在脚本中需要以根用户身份执行任务，但为了安全,不希望将根密钥硬编码在脚本里。
掌握角色信任策略 - 安全的基石
AssumeRole 的安全性完全取决于角色信任策略，这个策略定义了“谁”可以“扮演”这个“角色”。
- 核心技巧：遵循最小权限原则和精确授权。
- 常见错误：在信任策略中使用通配符 ，
"Principal": { "AWS": "arn:aws:iam::123456789012:root" }，这表示该账户下的任何用户或角色都可以扮演此角色,存在巨大的安全风险。 - 最佳实践：
- 针对特定角色授权：如果账户 A 的角色 B 要扮演账户 C 的角色 D，信任策略应该明确指定是账户 A 的角色 B。
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::ACCOUNT_A_ID:root" }, "Action": "sts:AssumeRole", "Condition": {} // 可以添加条件，如来源 IP } ] } - 针对特定用户授权：如果账户 A 的用户 E 要扮演账户 C 的角色 D，信任策略应明确指定用户 E。
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::ACCOUNT_A_ID:user/userE" }, "Action": "sts:AssumeRole" } ] } - 使用条件：可以添加更精细的控制，例如只允许来自特定 IP 地址或要求 MFA。
"Condition": { "Bool": {"aws:MultiFactorAuthPresent": "true"} }
- 针对特定角色授权：如果账户 A 的角色 B 要扮演账户 C 的角色 D，信任策略应该明确指定是账户 A 的角色 B。
善用会话策略 - 精细化权限控制
当你调用 AssumeRole 时，除了角色的权限策略，你还可以传入一个会话策略。
- 核心技巧：在扮演角色时，进一步收缩权限，会话策略会与角色的权限策略进行“与” (AND) 运算,最终得到的权限是两者的交集。
- 为什么需要它：想象一个场景，你有一个名为
PowerfulS3Admin的角色，它拥有所有 S3 的读写权限，你想让某个开发者只读取prod-bucket/logs这个路径，你可以：- 创建一个新的、权限受限的角色。 (可行,但角色会越来越多)
- 使用会话策略：让他仍然扮演
PowerfulS3Admin，但在调用AssumeRole时，附加一个只允许prod-bucket/logs/*的会话策略。
- 优势：避免了创建大量单一用途的角色,提高了角色的复用性。
示例 (使用 AWS CLI)：
# 假设角色arn是 arn:aws:iam::123456789012:role/S3ReadOnlyForLogs
# 会话策略文件 session-policy.json 内容如下:
# {
# "Version": "2012-10-17",
# "Statement": [{
# "Effect": "Allow",
# "Action": "s3:GetObject",
# "Resource": "arn:aws:s3:::prod-bucket/logs/*"
# }]
# }
aws sts assume-role \
--role-arn "arn:aws:iam::123456789012:role/S3ReadOnlyForLogs" \
--role-session-name "Dev-Debug-Session" \
--policy- file://session-policy.json
设置合理的会话持续时间
所有 STS 令牌都有有效期，默认为 1 小时，最长可配置为 12 小时。
- 核心技巧：遵循最小权限和最小时间原则。
- 最佳实践：
- 脚本/自动化任务：根据任务预计执行时间设置，15 分钟到 1 小时，不要设置为 12 小时。
- 人工操作：根据操作复杂度设置，1-4 小时，如果用户长时间不活动，令牌自动失效,减少凭证泄露的风险。
- 高风险操作：对于像删除资源这样的操作，甚至可以设置一个更短的时间（如 15 分钟），给用户足够的操作时间,但又不会太长。
整合 AWS CLI/SDK/工具链 - 让自动化更安全
STS 生成的临时凭证可以无缝集成到所有 AWS 工具中。
- 核心技巧：使用环境变量或配置文件来注入临时凭证,而不是硬编码。
- 场景：CI/CD 流水线 (如 Jenkins, GitLab CI)
- 在 AWS 中创建一个 CI/CD 专用的 IAM 角色，并配置好信任策略，允许你的 CI 系统扮演它。
- 在 CI 系统中，使用
aws sts assume-role命令获取临时凭证。 - 将返回的
AccessKeyId,SecretAccessKey,SessionToken设置为环境变量。 - 后续的
aws deploy,aws cloudformation deploy等命令会自动从环境变量中读取凭证，无需管理永久的 Access Key。# Jenkinsfile 或 CI 脚本示例 withAWS(credentials: 'aws-role-for-cicd', region: 'us-east-1') { sh 'aws s3 ls' // 这个命令会使用临时凭证 }
- 场景：本地开发
- 安装
aws-sso-util或aws-vault等工具。 - 通过
aws sso login或aws-vault login进行身份验证。 - 这些工具会自动调用 STS 获取临时凭证，并安全地存储或注入到你的 shell 会话中。
- 你现在可以直接在命令
- 安装
