📚 课程目录第2章 IAM用户、组和角色基础

2. IAM 用户、组和角色基础：创建用户、组、角色，分配基本权限

好了，我们正式开始动手。上一章我们把桶策略和IAM的关系理清了，这一章咱们得把地基打牢。毕竟，权限最终都是附着在“身份”上的。这个身份，在AWS里就是用户、组和角色。

我最早接触IAM时，觉得这东西不就是个账号管理吗？后来被生产环境狠狠教育了一回——权限给多了出事，给少了运维同事骂娘。说白了，IAM玩的是“最小权限”的艺术。来，我们一步步走。

2.1 IAM 用户：这是谁在用

IAM用户，代表一个具体的人或服务账户。每个用户有自己的一对访问密钥（Access Key ID + Secret Access Key）或者登录密码。

创建IAM用户的步骤（我习惯用CLI，但这里用控制台演示，更直观）：

登录AWS管理控制台，进入IAM服务。
点击“用户” → “创建用户”。
输入用户名（比如 zhang-san）。
勾选“提供用户对AWS Management Console的访问权限”。
设置密码（自动生成或自定义）。
（可选）要求用户下次登录时重置密码。嗯，安全最佳实践。
点击“下一步：权限”。

我的习惯： 创建用户时，我从不立即给权限。先创建好用户，放到组里，权限通过组去继承。这样后期管理，你想想看，改一个组，所有用户都生效，多省事。

2.2 IAM 组：批量管理的利器

组是个容器。你把用户扔进去，然后给组绑权限。所有组里的用户，自动继承这些权限。

为什么要用组？

批量操作：10个开发者，加一个“developers”组，一次性搞定。
权限隔离：运维组、开发组、财务组，各管各的。
简化审计：查看某个组绑了什么策略，比挨个查用户快得多。

创建组的示例：

1. 导航到IAM → “用户组” → “创建组”。
2. 组名：developers-team。
3. 附加策略：先不选，我们后面再细讲。
4. 创建完成后，把 zhang-san 和 li-si 两个用户加进去。

我经历过一个项目，忘了做组管理，直接给20多个用户单独绑策略。结果半年后有人离职，权限清理花了整整两天。从那以后，我立了个规矩：没有组的用户，不配拥有权限。

2.3 IAM 角色：给“临时工”用的权限

角色不是为某个用户永久保留的。它是一组权限，谁需要谁去“扮演”。你想想看，EC2实例要访问S3，你不能把访问密钥硬编码在代码里吧？这时候就该角色上场了。

角色的典型使用场景：

场景	说明
EC2 访问 S3	给EC2实例附加一个IAM角色，让它自动获取临时凭证去读写S3。
跨账号访问	公司A的某个用户，需要临时操作公司B的资源。通过角色信任关系搞定。
Lambda 执行权限	Lambda函数运行时，需要一个角色来决定它能调用哪些服务。

创建角色的流程：

点击“角色” → “创建角色”。
选择信任实体类型（哪个服务或账号可以扮演这个角色）。
附加权限策略（这个角色能有啥权限）。
设置角色名称（如 EC2-S3-ReadOnly-Role）。
创建完成。

避坑指南： 我曾经犯过一个大错：给EC2实例绑了一个“管理员权限”的角色。结果某天成员登录到实例上，直接用AWS CLI删了整个数据库。教训：角色的权限一定要收紧，能用“只读”绝不用“读写”，能用“单桶”绝不用“所有桶”。

2.4 分配基本权限：策略的绑定

权限是通过策略（Policy）来表达的。策略分两种：AWS 托管策略（AWS官方帮你写好的）和客户托管策略（你自己写的JSON）。

我这里直接给几个最常见的绑定示例：

给用户直接绑策略（不推荐，但演示用）：

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::example-bucket/*"
        }
    ]
}
// 这段策略只允许用户从 example-bucket 读取对象。

给组绑策略（推荐方式）：

// 创建一个名为 "DeveloperAccess" 的客户托管策略
// 然后挂载到 developers-team 组上
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "s3:ListBucket",
                "s3:GetObject"
            ],
            "Resource": "*"
        }
    ]
}

给角色附加策略：

在创建角色时直接选策略。比如给 EC2-S3-ReadOnly-Role 附加 AmazonS3ReadOnlyAccess 托管策略。这样，任何启动时使用了这个角色的EC2实例，都能读取S3里的东西。

  记得这个原则： 用户 -> 组 -> 策略，这是常规路径。角色是单独的，它通过“信任策略”让别人来扮演。理解了这个，你后面学桶策略的 Principal 字段会轻松很多。

2.5 核心逻辑框架图

下面这张图，是我自己画的理解IAM结构的思路。你看完这个，应该能明白用户、组、角色和策略之间的关系。

看完图你会发现，组和角色都指向策略，策略再指向资源。用户要么在组里间接获得权限，要么直接去扮演角色。这是两种完全不同的授权模型，后面讲桶策略的 Principal 时，你会频繁接触到这两个概念。

2.6 权限分配的最佳实践（我的经验总结）

能用组就别用直接绑定：哪怕只有两三个人，也建个组。万一以后要加人呢？
角色是给“机器”和“跨账号”用的：人登陆控制台用用户，程序跑任务用角色，别搞混。
策略先写最小权限，再逐步放开：我习惯先给个 Deny 全部，然后只 Allow 必要的行动。少了漏了再加，总比多了出安全问题强。
启用IAM Access Analyzer：它可以帮你分析哪些策略权限给多了，谁没在用。我每个季度都会跑一遍，清理一批僵尸权限。

一个小技巧： 创建角色时，你可以在“信任关系”标签页里指定只有特定用户、特定EC2实例或特定账号才能扮演它。这相当于给角色加了个“门卫”，只有符合条件的人才能进来拿权限。

这一章的内容到这儿。你把用户、组、角色、策略这四个概念捋顺了，后面的几乎所有IAM操作你都不会跑偏。我当初花了一周才彻底搞懂这几个东西的区别，但一旦理解了，后面看桶策略那种复杂JSON就跟看菜单一样简单。