Kubernetes 细粒度 kubelet 授权：为什么监控权限不能再粗放配置？
Kubernetes 1.36 中细粒度 kubelet API 授权进入 GA，本文从运维视角解释它对监控、安全和最小权限的影响。
kubelet 是每个 Kubernetes 节点上最关键的组件之一。很多监控系统、日志系统和运维工具都需要访问 kubelet API，但过去为了让工具工作，集群里经常会授予较宽的 nodes/proxy 权限。
这在小集群里看起来方便，但在生产环境里风险很高。权限过宽意味着一旦监控组件、Token 或服务账号被滥用，攻击者可能获得更多节点级能力。
Kubernetes 1.36 将细粒度 kubelet API 授权推进到稳定阶段，核心价值是让常见的监控和可观测性访问不再依赖过大的节点代理权限。
为什么这件事重要
运维权限设计有一个常见误区：只要组件是“内部系统”，权限就可以放宽。实际上，监控系统往往能访问大量节点、Pod、指标和标签，一旦被突破，影响面很大。
细粒度授权让你可以按 API 能力拆分访问边界。例如监控只需要读取指标，就不要给它代理节点、执行额外请求或访问无关接口的能力。
升级前要检查什么
升级 Kubernetes 前，先盘点所有访问 kubelet API 的组件：
- Prometheus 或 metrics-server
- 日志采集 Agent
- 节点巡检脚本
- 自研运维平台
- 安全扫描工具
然后检查它们当前使用的 ServiceAccount、ClusterRole 和 ClusterRoleBinding。重点看是否存在过宽的 nodes/proxy、nodes/* 或通配符权限。
推荐落地方式
第一步不要直接删除旧权限，而是在测试集群中启用新策略并观察监控是否正常。第二步为每类工具建立单独角色，不要让所有 Agent 共用一个大权限账号。第三步把权限变更写进升级文档，避免故障时临时加回通配符。
对企业来说，这类改动短期看是 RBAC 调整，长期看是安全基线升级。越早把 kubelet API 权限拆细，后续接入更多监控、安全和 AI 节点组件时越不容易失控。