防止越权操控守护进程的关键是rbac精准建模+命名空间隔离+权限边界收口，需限制daemonsets、nodes等资源的create/update/delete操作，禁止跨命名空间访问，绑定最小权限serviceaccount，并叠加networkpolicy与节点调度控制。
在多租户容器云平台中，防止越权操控守护进程（如 DaemonSet、Node 绑定的 Pod、kube-system 中关键组件）的关键，不是靠“禁止所有操作”，而是通过 Kubernetes 原生 RBAC 的精准建模 + 命名空间隔离 + 权限边界收口来实现。核心在于：守护进程天然具有节点级影响能力，必须从“谁可以创建/更新/删除”和“谁能看到/执行”两个层面同时设防。
聚焦守护进程资源类型，限制敏感动词
DaemonSet、Node、Pod（尤其是绑定到特定 Node 的）、ClusterRole/ClusterRoleBinding 等资源，是越权操控守护进程的高危入口。RBAC 规则中需显式排除或严格限定：
- 禁止普通租户使用 cluster-admin 或泛化 ClusterRole（如
system:node、system:kube-scheduler） - 对租户 Role/ClusterRole，禁用
create/update/delete操作于daemonsets、nodes、podsecuritypolicies（如启用）、clusterroles等资源 - 允许
get、list、watch仅限本租户命名空间内的 Pod，且明确排除--all-namespaces场景（可通过准入控制如 OPA 或 kubewarden 进一步拦截）
强制命名空间隔离，切断跨租户可见性
守护进程本身常运行在 kube-system 或全局命名空间，但租户不应有权限查看或干扰它们。做法包括：
- 为每个租户分配独立命名空间（如
tenant-a-prod），所有租户资源（含其自定义 DaemonSet）仅限该空间内部署 - 租户 Role 不赋予任何跨 namespace 权限；ClusterRole 仅用于极少数平台运维角色，并通过
ClusterRoleBinding绑定到具体 ServiceAccount，而非用户组 - 在
kube-system等系统命名空间上设置 deny-all RoleBinding，确保无租户账号（包括其 SA）能读取其中的 DaemonSet 或 Node 状态
用 ServiceAccount 替代用户直连，绑定最小权限角色
越权常源于“一个高权限账号多人共用”。应杜绝直接给用户分配 cluster-admin，转而为每类操作场景创建专用 SA：
- 开发调试用 SA：只允许
get/logs/exec本租户命名空间内 Pod，禁止访问nodes、daemonsets - CI/CD 流水线 SA：允许
create/update本租户命名空间内 Deployment/StatefulSet，但显式拒绝daemonsets和nodes - 监控采集 SA：仅允许
get本租户 Pod/Metrics，不可exec或delete
叠加网络与节点调度控制，阻断横向逃逸路径
即使 RBAC 限制了 API 操作，若租户 Pod 能直接访问宿主机或与其他租户 Pod 通信，仍可能间接干扰守护进程。需补充：
- 启用 NetworkPolicy，默认拒绝所有跨命名空间流量，仅允许租户内部必要通信
- 为租户工作负载配置
nodeSelector或tolerations，避免其 Pod 被调度到运行关键 DaemonSet（如日志采集、安全代理）的专用管理节点上 - 对系统节点打
taint（如node-role.kubernetes.io/control-plane:NoSchedule），确保租户 Pod 无法在其上运行
