集群运维权限控制的核心是“谁在什么范围内能做什么”，通过职责细分、分层授权（平台级+资源级）、标签化动态隔离及定期审计实现精准管控。
集群运维权限控制的核心不是“谁能不能做”，而是“谁在什么范围内能做什么”。职责细分的关键在于把人从操作者变成角色载体，用职责边界代替人工盯防。
按职能切分基础角色类型
先明确几类典型职责，再匹配对应权限范围：
- 集群管理者：负责节点增删、证书轮换、备份策略配置、集群升级。不涉及具体应用，但对集群稳定性有全局影响。
- 平台运维员：管理命名空间、服务网格、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次即触发通知。
不复杂但容易忽略
