别再给运维发“集群管理员”了：Kubernetes 最小权限这事，真不是形式主义
先说一句容易得罪人的大实话：
90% 的 Kubernetes 集群，权限设计是“摆设级别”的。
我见过太多现场是这样的👇
- 新同事第一天入职
👉「给他个cluster-admin，省事」 - 外包要排查问题
👉「临时给个管理员，回头再收」 - CI/CD 跑不起来
👉「算了，直接给全权限」
结果就是——
权限越给越大，锅却越背越多。
这篇文章，我不打算背书式讲 RBAC 定义，而是站在一个真被权限坑过的运维视角，聊三件事：
- Kubernetes 权限到底在控制什么
- RBAC / ABAC 到底“真身”是什么
- 最小权限到底该怎么一步步落地
一、先统一一个认知：K8s 权限 ≠ 登录权限
很多人一说权限，脑子里是：
“能不能进集群？”
但在 Kubernetes 里，真正的问题是：
进来以后，你能干什么？
K8s 权限控制的本质是这三件事：
- 对什么资源（Pod / Deployment / Secret）
- 能做什么动作（get / list / create / delete）
- 在什么范围（namespace / cluster）
所以你看到的那一长串：
verbs / resources / apiGroups
不是花里胡哨，是权力的拆解清单。
二、RBAC 和 ABAC，到底谁在干活？
1️⃣ RBAC：你现在 99% 在用的那个
RBAC（Role-Based Access Control）说白了就一句话：
你是谁 → 你属于什么角色 → 你能干什么
Kubernetes 官方主推，生态成熟，工具齐全。
典型对象只有四个：
- Role
- ClusterRole
- RoleBinding
- ClusterRoleBinding
举个最常见的例子：
👉 只读 Pod 的权限
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: pod-reader
namespace: dev
rules:
- apiGroups: [""]
resources: ["pods"]
verbs: ["get", "list"]
一句人话翻译：
在 dev 命名空间里，只能看 Pod，不能动。
2️⃣ ABAC：存在感很低，但你可能“间接用过”
ABAC（Attribute-Based Access Control）不是靠角色，而是靠属性规则：
- 用户名
- 资源类型
- 命名空间
- 请求动作
它的配置通常是 JSON 策略文件，比如：
{
"user": "ci-bot",
"namespace": "dev",
"resource": "pods",
"readonly": true
}
但说句实在的：
ABAC 更像 Kubernetes 的“前朝遗老”
- 不好维护
- 不好审计
- 不好动态变更
👉 结论很明确：生产环境，主用 RBAC，ABAC 了解即可。
三、为什么“最小权限”这么难落地？
不是你不想，而是现实真的很残酷。
❌ 困难一：没人知道“到底需要什么权限”
你问开发：
“你这个服务需要什么权限？”
他通常会说：
“能跑就行。”
但 Kubernetes 不接受这种模糊回答。
❌ 困难二：调试成本太高
权限太小的典型症状：
Error from server (Forbidden)
然后你开始：
- 加一个 verb
- 再试
- 再 Forbidden
- 最后一怒之下：给 cluster-admin
❌ 困难三：历史包袱太重
很多集群：
- 一开始就是 admin
- 后面业务叠加
- 再想收权，已经不敢动了
四、真正可落地的“最小权限设计法”
下面这套方法，是我这几年反复验证过的。
🧠 核心思想：权限不是一次性设计的，是“跑出来的”
Step 1：先拆身份，而不是拆权限
别一上来就写 Role。
先问三个问题：
- 这是 人 还是 程序？
- 是 长期账号 还是 临时任务？
- 是 运维 / 开发 / CI 哪一类？
我自己的原则：
人 ≠ 程序
CI ≠ 人
运维 ≠ 开发
Step 2：从“只读”开始，而不是“能跑”
给任何新身份，第一版永远是只读：
verbs:
- get
- list
- watch
为什么？
看不见系统，就谈不上安全操作。
Step 3：通过审计日志“反推”权限
这是很多人忽略的神器👇
kube-apiserver --audit-log-path=/var/log/k8s-audit.log
从 audit log 里，你能看到：
- 谁
- 对什么资源
- 做了什么
- 被拒绝还是允许
👉 这才是真实需求，而不是猜。
Step 4：按 namespace 切，而不是全局切
大部分业务根本不需要 ClusterRole。
优先：
- Role
- RoleBinding
- Namespace 隔离
kind: RoleBinding
metadata:
name: dev-reader-binding
namespace: dev
subjects:
- kind: User
name: dev-user
roleRef:
kind: Role
name: pod-reader
五、我个人最反感的三种权限“坏味道”
说点主观的。
🚫 1. cluster-admin 当万能钥匙
这不是效率，这是技术债炸弹。
🚫 2. CI/CD 用人的 kubeconfig
程序 ≠ 人
程序应该有自己的 ServiceAccount。
🚫 3. 权限没人敢删
“这个 Role 不知道谁在用，先留着吧。”
然后一留就是三年。
六、说点心里话：权限设计，其实是在保护你自己
很多人觉得：
“搞最小权限，麻烦。”
但我真心说一句掏心窝子的：
权限不是防黑客的，更多是防“自己人误操作”的。
真正出过事故的运维都懂：
- 删错 namespace
- 改错 Secret
- apply 到了 prod
那一刻你会无比庆幸：
“还好当时没给他删除权限。”
七、结尾送你一句我很喜欢的话
系统的成熟度，不是看功能有多强，而是看“不能做什么”有多清晰。
Kubernetes 最小权限，不是一次性工程，而是一个持续收敛的过程。
慢一点，保守一点，
但每一步，都是在给未来的自己减压。
