第2章：IAM角色概念与使用场景归纳
上一章我们聊了KMS的基础。这一章，我把核心放在
我习惯把IAM角色比喻成一个“马甲”。你穿上它就是另一个人，拥有另一套权限。脱下来，你又是原来的你。这个“马甲”本身没有用户名，没有密码，也没有永久密钥。它靠的是一套动态生成的临时凭证。
什么是IAM角色？
简单说，IAM角色就是一种AWS身份。跟IAM用户一样，角色也有权限策略。但不同在于：
- 角色没有登录密码
- 角色没有长期访问密钥
- 角色必须被“扮演”才能使用
谁会去扮演它？EC2实例、Lambda函数、或者另一个AWS账户的用户。甚至是你自己，通过控制台切换角色。
核心记忆点：IAM角色 = 权限集合 + 临时凭证。谁拿到谁用，用完就失效。
信任实体：谁可以扮演这个角色？
每个角色都有一个信任策略。这个策略定义了谁有资格来扮演角色。我在项目中遇到过有人忘记配置信任策略，结果角色权限再大也没法用。那叫一个尴尬。
信任策略的典型写法如下：
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "ec2.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}这段策略的意思是：允许EC2服务来扮演这个角色。Principal字段是关键，它指定了谁是被信任的实体。可以是AWS服务、IAM用户、IAM角色或者联合身份用户。
信任策略千万别写得太宽。我曾经见到有人把Principal写成*，结果任何AWS服务都能扮演这个角色。安全风险非常大。
权限策略：角色能做什么？
角色不止有信任策略，还有权限策略。权限策略决定的是：扮演了这个角色之后，你能执行哪些操作。
举个例子，你想让EC2实例能访问S3存储桶。你会这样做：
- 创建一个IAM角色，信任实体设为ec2.amazonaws.com
- 给角色附加S3只读权限的策略（比如AmazonS3ReadOnlyAccess）
- 在EC2实例的启动配置里，指定这个角色
这样，EC2实例就能通过角色获取临时凭证，去读取S3里的文件。整个过程不需要在代码里写死任何密钥。
我建议生产环境里，所有AWS服务间的访问都用角色，别用长期密钥。这是最基础的AWS安全黄金法则。
临时安全凭证：为什么IAM角色更安全？
IAM角色背后是AWS Security Service (STS)。当你扮演一个角色时，STS会给你返回一组临时凭证：
- AccessKeyId
- SecretAccessKey
- SessionToken
- Expiration（过期时间）
默认情况下，这些凭证的有效期从15分钟到1小时不等。过期后，系统会自动刷新。就算有人偷了你的临时凭证，也只能用一小段时间，影响范围可控。
我之前处理过一个信用卡泄露事件，就是因为有人在代码里硬编码了长期密钥。如果当时用的是IAM角色+临时凭证，这张信用卡根本不会泄露。
使用场景归纳
总结下我在实际工作中最常用的几种场景：
| 场景 | 说明 | 典型配置 |
|---|---|---|
| EC2访问其他AWS服务 | EC2实例需要调用S3、DynamoDB等 | 信任主体设为ec2.amazonaws.com |
| Lambda执行任务 | 无服务器函数需要操作AWS资源 | 信任主体设为lambda.amazonaws.com |
| 跨账户访问 | 账户A的用户需要管理账户B的资源 | 信任主体设为账户A的IAM用户 |
| 联合身份用户 | 使用Active Directory或Google登录 | 信任主体设为SAML或OIDC身份提供商 |
| 临时提升权限 | 平时用只读角色，执行敏感操作时切换到管理员角色 | 在控制台手动切换角色 |
IAM角色 vs IAM用户：选哪个？
选型其实不难。我列出对比，你一看就明白：
| 维度 | IAM角色 | IAM用户 |
|---|---|---|
| 永久凭证 | 没有 | 有（访问密钥可以永久有效） |
| 适用对象 | AWS服务、跨账户用户、外部身份 | 人类的长期操作、程序使用密钥 |
| 安全风险 | 低（临时凭证自动轮转） | 高（密钥可能泄露） |
| 生命周期 | 随时可以创建和删除 | 通常需要审批管理 |
我的建议很简单：凡是机器（EC2、Lambda、ECS等）要用的权限，一律用角色。只有人需要长期交互时，才考虑IAM用户。
实战避坑指南
说几个我踩过的坑：
- 忘记配置信任策略——角色创建后不能直接使用，必须指定谁可以扮演它。有些新手以为挂上权限策略就完事了。不对。
- 临时凭证过期导致服务中断——我遇到过Lambda函数里手动缓存了临时凭证，结果业务跑到一半过期了。切记，永远用SDK自动管理凭证刷新。
- 跨账户角色路径混乱——如果你在组织里多个账户共用角色，建议统一命名规范。我曾经在30个账户里找“哪个角色是谁建的”，查了一下午。
- 最小权限原则被忽略——有开发图省事，直接给角色挂了个AdministratorAccess。结果一个普通EC2被攻破后，整个账户沦陷。
这张图把IAM角色的三个核心部分串起来了：信任实体决定谁可以扮演，权限策略决定能做什么，临时凭证保证安全性。每次设计角色时，建议先过一遍这个图。
小结
这一章我们讲了IAM角色的本质、信任策略、权限策略和临时凭证。还有各种常见的使用场景。我个人观点是：角色是AWS里最安全、最灵活的身份管理方式。优先使用角色，少用长期密钥。这是我在多年实践中得出的结论。