IAM 角色基础
刚开始接触 IAM 角色的时候，我总觉得它不如密钥对那么直观。密钥就是一把钥匙，你给我我就能用。但是角色呢？它更像一个“空壳子”，谁穿上去谁就有权限。今天我们就把它彻底拆开看看。
角色的定义
说白了，IAM 角色就是一个没有长期凭证的 AWS 身份。用户有密码和访问密钥，角色没有。它只有一组临时的、自动轮换的凭证，由 AWS Security Service (STS) 颁发。
我记得有一次给客户设计跨账号访问方案，对方坚持要创建 IAM 用户然后把密钥发过去。我问他：“如果密钥泄露了怎么办？如果你那个员工离职了密钥怎么回收？”他沉默了几秒，然后说：“那你告诉我角色怎么做。” 嗯，那次之后我就知道，角色才是王道。
信任策略的作用
角色为什么能被别人“扮演”？关键就在信任策略（Trust Policy）。它是一份 JSON 文档，定义了 谁可以 扮演这个角色，以及 在什么条件下 可以扮演。
你想想看，如果角色是一个房间，信任策略就是门口的安检名单。名单上没有你，你就算走到门口也进不去。我曾经在排查一个跨账号失败问题时，反复检查权限策略没问题，最后发现信任策略里根本没写对方的账号 ID…… 那叫一个尴尬。
信任策略的结构
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::123456789012:root"
},
"Action": "sts:AssumeRole",
"Condition": {
"IpAddress": {
"aws:SourceIp": "203.0.113.0/24"
}
}
}
]
}Principal 指定谁可以扮演——可以是 AWS 账号、IAM 用户、IAM 角色，甚至是 AWS 服务（比如 EC2）。Condition 是可选的安全限制，比如限制来源 IP 或 MFA 状态。Action 固定为 sts:AssumeRole。
如何创建 IAM 角色
创建角色的过程其实不复杂，但我建议你用 Infrastructure as Code 来做，比如 Terraform 或 CloudFormation。手动点控制台容易漏掉细节。
- 在 IAM 控制台选择「角色」→「创建角色」。
- 选择信任实体类型：AWS 账户、AWS 服务、SAML/Web 身份等。
- 配置信任策略，指定谁可以扮演。
- 附加权限策略——决定角色扮演后能做什么。
- 添加标签（可选），方便管理和审计。
- 命名并创建。
这里有个坑：我遇到过有人把权限策略写进信任策略里，结果角色根本没权限。权限策略和信任策略是两张独立的策略，互不包含，千万别搞混了。
| 策略类型 | 作用对象 | 控制什么 |
|---|---|---|
| 信任策略 | 角色本身 | 谁可以扮演 |
| 权限策略 | 角色会话 | 扮演后能做什么 |
如何扮演 IAM 角色
扮演角色就是调用 sts:AssumeRole API，获取临时凭证。最常见的方式有：
- AWS CLI：
aws sts assume-role --role-arn "arn:..." --role-session-name "test" - 控制台切换：在右上角用户菜单里选「切换角色」。
- SDK/API：程序里调用 AssumeRole 拿到临时 AK/SK/SessionToken。
- EC2 实例元数据：给 EC2 关联实例角色，自动获取临时凭证。
实际操作中，我推荐用 aws sts assume-role 加上 --duration-seconds 参数控制有效期。默认 1 小时，最长 12 小时（角色允许的话）。临时凭证有 Expiration 字段，过期后会返回 AccessDenied，代码里要做好凭证刷新逻辑。
角色基础知识结构图
下面这张图总结了 IAM 角色的核心概念和关系。你可以对照着理清信任策略、权限策略、扮演流程的脉络。
在实际项目中，我还会把角色与组织（AWS Organizations）结合使用，实现整个企业的权限统一管理。但那已经是后话了。先把基础打牢，后面的技巧才能用起来。