6.1 IAM 与桶策略：最小权限落地
6.1 IAM 与桶策略：最小权限落地
本节摘要：MinIO 的身份体系由用户、组、策略三层构成，策略是一份声明"谁可以对哪些资源做哪些动作"的 JSON,评估顺序遵循"显式拒绝压倒一切、有允许则放行、默认拒绝"的铁律。本节按这套模型给出最小权限的标准落地姿势。
先把身份模型定义清楚
MinIO 的访问控制回答一个问题："这个请求，放不放行？"答案由三层结构共同给出：
用户（user）：最细的身份单位，由 AccessKey 与 SecretKey 标识。集群初始化时的 root 账号是特殊用户，拥有不可剥夺的全部权限——也正因如此，root 凭证只该出现在初始化与应急场景。
组（group）：用户的集合，策略可附加在组上，组内用户批量继承。人随岗位进组、离岗出组，权限跟着组走而不跟着人走。
策略（policy）：JSON 文档，声明动作（action）、资源（resource）与效果（allow 或 deny）。策略附加到用户或组上生效；MinIO 内置了从只读到管理的几档常用策略，自定义策略则完全对齐 AWS IAM 语法。
与这套体系并列的还有服务账号（service account）：为某个已有身份派生的子凭证，权限永远是其父身份的子集，常发给应用或第三方系统，泄露时可单独吊销而不动父账号。
策略评估的铁律
一个请求进来，策略评估按固定的优先级走，顺序不可协商：
- 显式拒绝（deny）命中，直接拒绝。 任何一条策略里的 deny 匹配到请求，游戏结束——哪怕另一条策略明确允许。
- 无拒绝且有一条允许（allow）命中，放行。
- 两者都没有，隐式拒绝。 没写就是不行——这是与很多老系统最大的差异，最小权限的默认姿态。
理解这条铁律，就理解了两个工程习惯：写策略时"先给允许、需要收紧时加拒绝"；排错时"先看有没有 allow,再全局搜 deny"——大多数 AccessDenied 的根因是第 3 条，压根没人给它发过通行证。
图 6-1 一次请求的策略评估路径
标准落地：为备份系统开一个最小权限账号
讲完模型，把它兑现在最常见的场景上：给备份系统发一套凭证，只允许它写自己的桶、读自己的桶，别的什么都不许。
# 1. 建用户 mc admin user add fleet backup-svc 'S3cure-Pass-2026!' # 2. 写自定义策略:只对 backup-* 前缀的桶开放读写,拒绝删除版本 cat > backup-policy.json <<'EOF' { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": ["s3:PutObject", "s3:GetObject", "s3:ListBucket"], "Resource": ["arn:aws:s3:::backup-*", "arn:aws:s3:::backup-*/*"] }, { "Effect": "Deny", "Action": ["s3:DeleteObject", "s3:DeleteBucket"], "Resource": ["arn:aws:s3:::backup-*", "arn:aws:s3:::backup-*/*"] } ] } EOF # 3. 创建并附加策略 mc admin policy create fleet backup-writer backup-policy.json mc admin policy attach fleet backup-writer --user backup-svc
三处细节体现设计意图：资源 ARN 里的前缀通配把访问圈死在 backup 开头的桶；显式 deny 删除动作是为"备份系统永远不该删源数据"上的第二道锁——即便策略写错给了删除权限，deny 仍然兜底；服务账号再派生——如果备份软件本身支持多套凭证，从 backup-svc 派生服务账号下发，吊销粒度更细。
内置策略（readonly、readwrite、writeonly、diagnostics、consoleAdmin）适合快速起步与演示，生产系统建议全部走自定义策略——内置档位的粒度是"桶里的所有东西"，与最小权限的精神不符。
与企业身份源的对接
人多起来的团队不应该在 MinIO 里手工管用户。MinIO 支持 OIDC 与 LDAP 两种外部身份源：员工用公司统一账号登录控制台与 API,MinIO 只负责把身份映射到策略。典型配置是 OIDC Claim Policy:身份令牌里的某个字段（如部门或角色声明）映射到预定义的策略名，登录即获得对应权限。这条路径把"人"的权限管理交还给身份数据的源头——入职离职自动生效，MinIO 侧零手工。S3 API 的机器访问则继续走本地用户或服务账号，人机分流。
本节要点回顾
- 三层模型：用户、组、策略，外加服务账号作为可单独吊销的应用凭证。
- 评估铁律：显式拒绝压倒一切，有一条允许就放行，默认隐式拒绝。
- 最小权限的落地件：前缀通配圈资源、显式 deny 兜底高危动作、服务账号派生。
- 人走身份源：OIDC 与 LDAP 把员工权限管理交还给身份数据源头。
模型清楚了，如果报错还是来了呢？下一节把主线案例办到底——一次完整的 AccessDenied 取证。
策略变量与更细的圈法
自定义策略还支持变量插值：资源或条件字段里可以引用请求者的属性（如用户名、会话标签），实现"每个用户只能访问以自己名字命名的前缀"这类模板化授权。用变量改写上面备份策略的资源字段，就能把"每应用一套策略"收敛为"全部门一套策略"——策略数量减一个数量级，审计面随之缩小。变量虽好，别贪多：模板化授权的可读性随变量数量急剧下降，一套策略里超过两个变量就该重新考虑结构。
三个管理面疑问
策略改了之后要重启或重登吗？
不需要。策略与绑定关系即时生效，下一次请求就按新策略评估。即时生效是把双刃剑：修复快，误伤也快——生产环境的策略变更同样要走变更流程与双人复核，6.2 的事故就是教训。
组策略与用户策略会叠加吗？
会。用户的显式绑定与所在组的绑定共同参与评估，任何一个来源命中 allow 即算数，任何一个来源的 deny 即拒绝。这带来一个排错技巧：排查权限问题时，把"用户直绑"与"组继承"两类绑定都列出来比对，6.2 案例里被删的正是组绑定那一路。
内置策略还有存在的必要吗？
有，但场景收窄到两处：临时排查（快速给一个账号只读以验证问题面）与测试环境。生产稳态的权限资产应当全部是自定义策略——名字见文知义、内容经过评审、变更留有痕迹，这三样内置档位都给不了。