Kubernetes 如何用细粒度授权保护 Kubelet API？
题干与适用场景
平台团队需要允许 kube-apiserver 读取节点指标，却不能让同一身份访问 Kubelet 的调试或执行接口。集群从旧的粗粒度授权行为升级到 Kubernetes v1.36，要求不中断监控、限制节点越权并保留审计证据。请说明认证链路、授权属性、迁移步骤、失败回滚与验证指标。
面试官考察点
- 是否区分 Kubelet HTTPS 端点的认证与授权，而不是只谈 RBAC。
- 是否能用 verb、resource、subresource、node 和 namespace 等属性表达最小权限。
- 是否理解 API Server 使用的 Kubelet 客户端身份必须拥有明确的授权规则。
- 是否能设计兼容迁移、拒绝默认放大、审计与回滚。
回答前需要澄清的问题
- 哪些调用方需要 Kubelet API：仅 API Server、监控代理，还是运维人员也直连节点？
- 需要哪些能力：指标、日志、运行中容器信息，还是执行命令和端口转发？
- Kubelet 使用客户端证书还是其他认证方式，API Server 的授权回调是否可用？
- 升级期间是否允许短暂只读降级，监控的不可用预算是多少？
30 秒回答框架
先把链路拆成三层：TLS 或其他认证确认调用者身份，Kubelet 授权器把请求映射成属性，随后通过 API Server 的授权接口做决策。再用最小权限规则只放行需要的节点端点，尤其把调试、执行和代理类能力单独隔离。迁移时先盘点调用矩阵、在审计模式观察拒绝、逐步收紧规则，验证指标和回滚开关后再切换为强制拒绝。
分步骤深入解答
1. 认证、授权与请求属性
Kubelet 的 HTTPS 端点先验证客户端证书或配置的认证方式，得到用户名和组。授权阶段把 HTTP 请求映射为 Kubernetes 授权属性，例如 verb、resource、subresource、namespace、name 和 node。认证成功不等于授权成功；每个端点都应经过授权检查。API Server 访问 Kubelet 时使用 --kubelet-client-certificate 和对应私钥代表一个受控身份，该身份必须在授权系统中拥有明确权限。
2. 用子资源表达最小权限
将指标读取、日志读取、容器状态和调试执行视为不同能力。优先授权只读的节点相关资源或子资源，并按节点范围限制；不要为了让监控工作而授予通配资源或 nodes/proxy 的宽权限。对执行命令、端口转发、调试接口单独建立高风险角色，默认不绑定给 API Server 的服务身份。
3. 迁移与兼容策略
先从现有审计和访问日志生成调用矩阵：身份、路径、动词、目标节点、结果和调用方版本。启用细粒度授权后，使用非强制观察阶段记录将被拒绝的请求，补齐必要的最小规则，再逐批切换节点。Kubernetes v1.36 中 KubeletFineGrainedAuthz 已 GA 并默认启用，升级前应确认发行版默认值、API Server 客户端凭证和所有监控组件的请求路径。
4. 观测、回滚与安全边界
为允许和拒绝分别记录审计事件、身份、节点、资源和原因，监控授权延迟、拒绝率、指标采集成功率及异常路径访问。若升级导致监控中断，先回滚客户端权限或暂时恢复兼容规则，同时保持高风险端点关闭；修复后再逐步收紧。网络层仍应限制 Kubelet 端口可达范围，授权不能替代 TLS、网络隔离和节点身份保护。
高质量示范回答
我会先确认 Kubelet 端点的认证方式，再把每个请求映射成标准授权属性。API Server 使用受控客户端证书访问 Kubelet，授权系统按 verb、resource、subresource、node 和 namespace 做最小权限判断。指标采集只获得必要的只读能力，exec、端口转发和调试接口使用独立高风险角色，不把通配权限或 nodes/proxy 绑定给普通服务身份。
迁移分四步：盘点调用矩阵；在观察阶段记录拒绝而不影响现有采集；按节点和组件批次补齐最小规则；最后切换到强制拒绝并设置回滚开关。v1.36 的 KubeletFineGrainedAuthz 已 GA 且默认启用，但我会验证发行版配置、API Server 客户端凭证和监控组件版本。审计中保留身份、节点、资源、结果与原因，网络策略继续限制 Kubelet 端口，确保授权、传输和网络三层同时收敛。
常见错误
- 只配置 TLS 认证，误以为拿到客户端证书就能访问所有 Kubelet API。
- 用通配资源或宽泛的
nodes/proxy解决监控问题。 - 没有列出调用矩阵就直接启用强制拒绝，导致升级后采集静默失败。
- 把 API Server 身份和运维调试身份共用同一个高权限角色。
- 只依赖授权规则，忽略 Kubelet 端口网络暴露和审计告警。
追问及应对
追问一：为什么不能直接给监控身份 nodes/proxy？
nodes/proxy 代表通过 API Server 代理访问节点端点的能力，范围可能覆盖远多于指标读取的路径。应先确认实际请求，再授予具体资源或子资源权限；如果实现限制必须使用代理权限，也要配合专用身份、节点范围和审计告警。
追问二：升级时如何证明没有放大权限？
比较升级前后的调用矩阵和授权决策，重点检查新增 verb、资源、子资源和节点范围。对拒绝事件做差异分析，使用合成请求验证指标可读而执行接口不可读，并将结果纳入发布门禁。
追问三：Kubelet 授权服务不可用时怎么办？
采用明确的故障关闭策略，避免授权回调失败变成默认放行。根据业务预算保留短时只读缓存或暂停采集，但不能为恢复监控而开放高风险端点；同时告警并在回调恢复后重试验证。