集群运维权限控制的核心是“谁在什么范围内能做什么”，通过职责细分、分层授权（平台级+资源级）、标签化动态隔离及定期审计实现精准管控。

集群运维权限控制的核心不是“谁能不能做”，而是“谁在什么范围内能做什么”。职责细分的关键在于把人从操作者变成角色载体，用职责边界代替人工盯防。

按职能切分基础角色类型

先明确几类典型职责，再匹配对应权限范围：

• 集群管理者：负责节点增删、证书轮换、备份策略配置、集群升级。不涉及具体应用，但对集群稳定性有全局影响。
• 平台运维员：管理命名空间、服务网格、Ingress规则、存储类（StorageClass）等平台层资源，不触碰业务Pod或配置项。
• 应用运维员：仅在指定命名空间内操作工作负载、ConfigMap、Secret、Service，无权修改网络策略或扩缩容底层节点。
• 只读监控员：可查看所有集群指标、日志聚合、告警历史，但不能触发任何写操作，包括静默告警或刷新仪表盘。

权限必须分层绑定，不可混用

单一角色无法覆盖全部场景，需组合使用两层授权机制：

• 平台级权限（如IAM或Rancher全局角色）：决定用户能否看到集群列表、创建新项目、管理认证源。例如，“标准用户”可访问集群，但无权新建集群；“只读用户”连集群列表都不可见。
• 资源级权限（Kubernetes RBAC或CCE命名空间权限）：决定用户在某个集群或命名空间内能做什么。比如给某人分配cluster-admin角色，但仅绑定到monitoring命名空间，他仍无法动生产环境的Deployment。

两者独立生效，叠加判断。缺任一层，操作即被拒绝。

用命名空间+标签实现动态隔离

静态角色不够用时，靠资源属性进一步收束权限：

• 为不同业务线的命名空间打标签，如team=finance、env=prod；
• 在Role中通过resourceNames或labelSelector限制只能操作带特定标签的资源；
• 例如：运维员A的角色规则里写namespaceSelector: matchLabels: { team: dev }，他就只能管开发团队的命名空间，哪怕其他命名空间也对他开放了相同API权限。

定期审计与权限回收机制

职责会变，权限不能一劳永逸：

• 每季度检查角色绑定记录，确认用户是否仍在对应岗位；
• 员工转岗或离职时，立即禁用其所在用户组，而非仅删除个人账号；
• 对高危操作（如delete nodes、patch secrets）开启审计日志，并设置告警阈值，比如1小时内同一角色执行超3次即触发通知。

不复杂但容易忽略