📚 课程目录第2章用户、组和角色的创建与管理

用户、组和角色的创建与管理：控制台与CLI操作

好，咱们进入第二章节。说实话，用户、组、角色，这三个东西是IAM里最基础也最容易被搞混的概念。我见过不少团队，一开始图省事，所有开发都用一个IAM用户，权限直接怼满……后来出了安全事件才追悔莫及。嗯，今天咱们就一步步把这三者掰扯清楚。

我的做法是：先搞清楚“谁”能用AWS，“怎么能用”，“能用什么”。用户对应“谁”，组和角色对应“权限包的组合”。你想想看，现实中公司里也是一样——新员工入职，先分到某个部门（组），再根据岗位分配临时权限（角色）。AWS把这件事抽象得挺清楚的。

2.1 IAM 用户：唯一身份的起点

IAM 用户，就是一个人或一个服务账号在AWS里的身份证。每个用户有唯一的ARN和凭证（密码或访问密钥）。

控制台创建用户（最常见场景）

登录 AWS 控制台，进入 IAM 服务。
左侧点“用户” → “创建用户”。
填写用户名（注意：全局唯一）。
勾选“访问密钥 – 编程访问”和“密码 – 管理控制台访问”。
设置密码策略（自动生成 or 自定义）。
附加权限：
- 直接附加策略（适合临时测试，不推荐生产）
- 加入组（推荐！权限集中管理）
- 复制现有用户权限
审核 + 创建，保存安全凭证（密钥只会出现一次，我吃过这个亏，后来都自动化保存到Secrets Manager）。

个人小经验： 我习惯在创建用户时强制要求“用户下次登录时重置密码”。另外，永远不要为根用户创建访问密钥——根用户是用来干买买买和开账单的，日常干活请用IAM用户。

CLI 创建用户

用 CLI 创建，说白了就是把控制台的按钮变成一行命令。适合脚本批量操作：

# 创建用户
aws iam create-user --user-name dev-alice

# 创建访问密钥
aws iam create-access-key --user-name dev-alice

# 设置控制台密码（强制重置）
aws iam create-login-profile \
  --user-name dev-alice \
  --password TempPass123! \
  --password-reset-required

# 附加策略（直接）
aws iam attach-user-policy \
  --user-name dev-alice \
  --policy-arn arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess

注意了：CLI 创建的用户默认没有任何权限，你必须显式给策略。否则用户干瞪眼。我曾遇到过新同事刚入职，配置完用户后死活无法访问S3——一查，权限没挂。

2.2 IAM 组：权限的容器

组，说白了就是把权限打包，然后往里面加人。一个用户可以在多个组里，子承父业般继承所有组权限。组没有登录凭证，不能单独做操作。

控制台创建组

IAM → 用户组 → 创建组。
填写组名（有意义的命名风格，比如 dev-s3-readonly）。
搜索并附加策略（支持通配符？不行，但可以选托管策略或内联策略）。
创建完成。然后去用户管理页面把用户加进来。

CLI 创建组并关联策略

# 创建组
aws iam create-group --group-name dev-s3-readonly

# 附加托管策略
aws iam attach-group-policy \
  --group-name dev-s3-readonly \
  --policy-arn arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess

# 把用户加入组
aws iam add-user-to-group \
  --user-name dev-alice \
  --group-name dev-s3-readonly

我曾经踩过的坑： 组内用户数量上限无限制，但是组的策略不能超过 5 个（一个组最多 5 个托管策略 + 1 个内联策略）。如果你因为业务需要很多小策略，建议合并成一个自定义策略挂上去。否则你会一直收到“策略数量超限”的报错。

2.3 IAM 角色：临时权限的通行证

角色和用户的最大区别：角色没有长久的密钥，它靠的是临时凭证（STS）。角色可以被用户、服务、甚至外部身份提供商“扮演”。我常跟团队说：【角色是一个帽子，谁戴上谁就有对应权限】。

控制台创建角色

IAM → 角色 → 创建角色。
选择信任实体类型：
- AWS 服务（比如EC2、Lambda）
- 另一个 AWS 账户（跨账号授权）
- Web 身份（Cognito、Google、Facebook）
- SAML 2.0 联合身份
选择使用场景（如EC2要用 ec2.amazonaws.com 作为服务主体）。
附加权限策略（这一步和用户组很像，不同的是角色可以有信任策略）。
给角色起名字（建议带环境或用途，比如 dev-ec2-s3-read）。
创建完成后，角色ARN形如：arn:aws:iam::123456789012:role/dev-ec2-s3-read。

CLI 创建角色

创建角色需要两步：先写信任策略（谁可以扮演这个角色），再挂载权限策略。

# step1: 创建角色并附加信任策略（文件 trust-policy.json）
# trust-policy.json 内容:
# {
#   "Version": "2012-10-17",
#   "Statement": [{
#     "Effect": "Allow",
#     "Principal": {
#       "Service": "ec2.amazonaws.com"
#     },
#     "Action": "sts:AssumeRole"
#   }]
# }

aws iam create-role \
  --role-name dev-ec2-s3-read \
  --assume-role-policy-document file://trust-policy.json

# step2: 附加权限策略
aws iam attach-role-policy \
  --role-name dev-ec2-s3-read \
  --policy-arn arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess

关键区别： 用户和组不能跨账号，但角色可以。角色扮演的本质是通过 sts:AssumeRole API 获取临时安全令牌。这个临时令牌默认有效期 1 小时（最长 12 小时，需要管理员配置）。

2.4 三者关系 & 典型场景

为了让你一眼就看清楚，我画了一张结构图。说实话，刚接触IAM的人最容易搞混的就是“组和角色的区别”。组是“把人归类”，角色是“被谁扮演”。别记反了。

维度	用户	组	角色
凭证类型	密码（控制台）或访问密钥（API）	无凭证	临时安全令牌（STS）
跨账号	否	否	是（通过信任策略）
主要用途	识别真实人员/服务	批量管理用户权限	服务间授权、跨账号访问、联合身份
创建方式	控制台/CLI/CloudFormation	控制台/CLI/CloudFormation	控制台/CLI/CloudFormation
删除影响	用户消失，凭证失效	组内用户不再继承该组权限	正在使用的角色会话会持续到过期

2.5 避坑指南 & 最佳实践

我曾经遇到过的一个经典事故：有个团队用CLI批量创建了100个IAM用户，直接挂了一个超大的PowerUserAccess策略。后来审计发现，其中一台开发机的密钥泄露了，攻击者拥有了所有S3、DynamoDB、EC2的权限，造成了数据泄露。问题在哪？——没有使用组，没有最小权限。

所以，记住这几个原则：

用户只加组，不贴策略。直接贴策略会让权限分散，审计困难。你能在组里查到所有拥有S3读权限的人。
角色优先用于服务间交互。EC2要读S3？建个角色挂到EC2上，别再往EC2里放密钥了。我见过太多人在代码里写死Access Key。
使用路径（Path）：创建用户或角色时指定路径，比如 /prod/、/dev/。虽然不影响权限，但在资源过多时，路径可以帮你做组织过滤。
CLI 使用前先验证：用 aws iam list-users 或者 aws iam get-group 检查一下当前状态。别一口气跑100个创建，结果发现组名重复。

我的个人惯用“三板斧”：

先建组，挂上托管策略（如 ReadOnlyAccess）。
再建用户，扔进组里。密码让它自动生成，首次登录强制改。
需要跨账号访问时，直接创建角色，指定信任账户ID，然后在目标账号那边用 sts:AssumeRole 切换。

这三步走完，80%的场景就覆盖了。剩下20%的场景——比如细粒度资源标签控制、会话长度限制——后面章节会展开。

最后提一句：控制台适合少量配置、学习、可视化管理；CLI适合批量、自动化与代码化（Infrastructure as Code）。两者结合，生产效率能翻倍。嗯，这一章先到这儿，你自己在沙箱环境里试试创建一组用户、组和角色，感受一下区别。