K8s权限管理的核心是用 RBAC、命名空间、服务账号和审计机制，把“谁能访问哪些资源、能执行什么动作、影响范围有多大”定义清楚。企业集群不能长期依赖管理员账号共享，也不能让所有团队都拥有集群级高权限。
为什么K8s权限管理容易被低估
很多团队早期为了方便，会直接使用 kubeconfig 管理员账号操作集群。短期看效率高，但风险非常大：
- 误删资源影响整个集群
- 无法区分是谁执行了变更
- 研发、测试、运维权限边界不清
- CI/CD 流水线持有过高权限
- 不同团队之间缺少隔离
Kubernetes 集群一旦承载多个业务团队，就必须从“能用”转向“可控、可审计、可隔离”。
RBAC的基本组成
RBAC 主要由四类对象组成：
| 对象 | 作用 | 典型用途 |
|---|---|---|
| Role | 定义命名空间内权限 | 允许查看Pod、更新Deployment |
| ClusterRole | 定义集群级权限 | 管理节点、存储类、全局资源 |
| RoleBinding | 把Role绑定给用户或服务账号 | 给某团队命名空间权限 |
| ClusterRoleBinding | 绑定集群级权限 | 给平台管理员或控制器权限 |
权限动作通常包括 get、list、watch、create、update、patch、delete。设计权限时应按最小权限原则，只给完成任务所需的动作和资源范围。
命名空间是权限隔离的第一层
命名空间不是强安全边界，但它是 Kubernetes 多团队管理中最常用的逻辑隔离方式。企业可以按团队、项目、环境拆分命名空间，例如：
- team-a-dev
- team-a-prod
- payment-prod
- data-platform-test
然后把不同角色绑定到对应命名空间，避免一个团队误操作另一个团队的资源。对于生产环境，还应结合网络策略、资源配额和准入控制形成更完整隔离。
企业常见角色设计
企业可以把角色分为几类：
- 集群管理员：负责节点、存储、网络、控制面和全局策略。
- 平台管理员：管理命名空间、配额、模板、发布策略和平台集成。
- 应用负责人：管理本应用的 Deployment、Service、ConfigMap 等资源。
- 只读观察者：查看状态、日志、事件和监控，不允许变更。
- 流水线服务账号：只允许在指定命名空间执行发布所需动作。
最容易出问题的是流水线账号。为了方便发布，很多团队给 CI/CD 账号绑定集群管理员权限，结果一条错误脚本就可能影响所有业务。
权限管理落地步骤
第一步：梳理用户和系统身份
先区分人和机器。人包括研发、测试、运维、安全、平台管理员；机器包括流水线、控制器、自动化脚本和监控组件。
第二步：按命名空间划分责任边界
确定哪些团队能访问哪些命名空间，开发、测试、生产环境是否分开授权。
第三步：建立角色模板
不要为每个人临时写权限。应沉淀应用管理员、发布账号、只读账号、运维账号等模板。
第四步：开启审计和定期复查
权限不是配置一次就结束。人员变动、项目下线、系统迁移后，都需要回收无效权限。
常见风险
ClusterRoleBinding滥用
集群级绑定影响范围大，应严格限制。绝大多数研发和流水线账号不需要集群级权限。
Secret读取权限过宽
能读取 Secret 的账号可能间接获得数据库密码、Token 或证书信息。Secret 权限要单独关注。
只做RBAC，不做网络隔离
RBAC 控制 API 操作权限，不等于控制业务流量访问。多租户场景还需要 NetworkPolicy 或服务网格策略。
权限没有审计
没有审计日志，就很难在误操作、安全事件或变更追溯时定位责任和影响范围。
平台化治理建议
企业级 Kubernetes 权限管理最好不要完全依赖手写 RBAC YAML。平台应提供：
- 用户和企业身份源集成
- 角色模板和审批流程
- 命名空间级授权
- 服务账号权限最小化
- 操作审计和权限报表
- 多集群统一权限视图
灵雀云 ACP 这类平台的优势在于把多集群、权限、命名空间、审计和资源治理放到统一入口，适合多团队共享集群和私有化生产环境。
RBAC要从最小权限开始设计
K8s 权限管理最常见的问题，是为了方便给研发、流水线或运维账号过大的权限。短期看减少了申请流程，长期会放大误操作和安全事件影响。RBAC 设计应从角色职责出发，而不是从“谁要什么权限”临时追加。
建议至少区分：
- 平台管理员：管理集群、节点、插件和平台级策略。
- 项目管理员：管理项目内命名空间、成员和资源配额。
- 研发人员：查看和操作指定环境的应用对象。
- 运维人员：查看日志、事件、告警和执行受控操作。
- 流水线账号：只拥有发布所需的最小权限。
RBAC 的安全目标不是阻碍效率，而是让每个账号只能影响它应该影响的范围。
多租户场景要配合审计和准入
只配置 RoleBinding 不足以完成企业级治理。生产集群还需要审计日志记录敏感操作，通过准入策略限制高危资源，通过命名空间和网络策略控制租户边界。否则权限看似隔离，实际仍可能通过特权容器、hostPath 或过宽 ServiceAccount 扩大影响。
建议定期检查 cluster-admin 绑定、长期未使用账号、默认 ServiceAccount 权限和生产命名空间变更记录。权限治理不是一次性配置，而是持续运营。
结语
K8s权限管理不是给几个人发 kubeconfig，而是建立一套身份、角色、命名空间、审计和最小权限体系。越早把权限边界设计清楚，后续多团队协作、生产发布和安全合规就越可控。
FAQ
RBAC能完全实现K8s多租户安全吗？
不能。RBAC 主要控制 API 权限，多租户还需要命名空间规划、资源配额、网络策略、镜像准入、审计和运行时安全配合。
开发人员是否应该有生产命名空间写权限？
不建议默认拥有。更稳妥的方式是通过流水线、审批和发布平台执行生产变更，开发人员保留必要的只读排查权限。
ServiceAccount权限为什么重要？
Pod 内应用和流水线常通过 ServiceAccount 调用 Kubernetes API。如果权限过大，应用漏洞或脚本错误可能扩大影响范围。
如何发现权限过度授权？
可以定期检查 ClusterRoleBinding、Secret 读取权限、长期未使用账号、通配符权限和跨命名空间授权，并结合审计日志确认实际使用情况。
