在 Kubernetes 集群中，有一个关键组件管理着每个节点的“生杀大权”，却也往往成为攻击者最想控制的突破口。
当你评估 Kubernetes 集群的安全态势时，有一个组件的重要性极高却常被忽视——它运行在每个计算节点上，手握创建容器、挂载存储、执行命令的实权，却可能因为配置不当而门户大开：kubelet API。
一、kubelet API：每个节点上的“行政主管”
把 Kubernetes 控制平面（如 kube-apiserver）想象成公司的“总部董事会”，负责制定战略和发布指令。每个工作节点就像一家独立运营的分公司。kubelet，则是分公司的行政主管。
-
它是什么？
kubelet 是运行在每个工作节点（物理机或虚拟机）上的代理程序。它的核心职责是接收来自“总部”（控制平面）的指令，并确保本节点上的 Pod（容器组）按预期运行。
而 kubelet API，就是这位主管对外沟通的“工作电话”和“命令执行窗口”。
-
它部署在哪里？
它直接部署并运行在每个工作节点的宿主机操作系统上，通常以系统服务（如 systemd 服务）的形式存在。这意味着它不在容器内部，而是与宿主机共享内核和网络命名空间，天然拥有更高的本地权限边界。
-
它的工作原理是怎样的？
kubelet 会持续处理两类指令来源：
- 来自“总部”的命令：它主动连接 kube-apiserver，接收“本节点应该运行哪些 Pod”的清单（PodSpec）。
- 处理外部直接请求：它同时开启一个 HTTPS 服务端（默认端口 10250），这就是 kubelet API。通过这个 API，不仅可以查询节点和 Pod 状态，更关键的是，它还能执行容器内命令、获取容器日志、甚至进行端口转发。
二、敏感端口：为什么 10250 端口如此危险
默认情况下，kubelet API 服务会在 所有网络接口（0.0.0.0） 的 10250 端口上监听，这直接扩大了安全暴露面：
-
高危操作暴露
/exec：可以在运行的容器中执行任意命令。/run：可以启动新容器。/logs：可以抓取所有容器日志，日志中可能包含敏感信息。/portForward：可以建立到容器的网络隧道。
-
认证与授权薄弱环节
在早期版本或配置不当的集群中，kubelet 可能启用匿名访问，或仅依赖较弱的客户端证书认证。
一旦攻击者能访问该端口，就可能直接控制节点上的 Pod，进一步窃取数据、植入后门或进行横向移动。相关加固讨论也可在 云原生/IaaS 场景中对照你的集群架构逐项核对。
三、关键加固：用宿主机网络隔离降低暴露面
直接回答一个常见且核心的问题：是的，将 Pod 配置为不使用宿主机网络，是降低 kubelet API（10250 端口）暴露风险的关键且有效的一环。
但这只是“一环”，需要放在整体纵深防御中理解。
攻击路径假设：如果攻击者成功进入某个 Pod（例如利用应用漏洞拿到容器权限，甚至进一步触发容器逃逸风险），而该 Pod 又共享宿主机网络命名空间（hostNetwork: true），那么攻击者从容器内部就能直接访问宿主机本地回环地址（127.0.0.1）的 10250 端口，从而绕过外部网络防火墙与边界隔离策略。
防护措施：禁用或严格控制 hostNetwork
-
原理
确保业务 Pod 运行在独立的 Pod 网络命名空间（默认且理想的状态）。即使容器被攻破，攻击者也难以直接触达宿主机本地敏感管理端口（包括 10250、10255 等），从而被限制在 Pod 网络沙箱中。
-
实施
- 在 Pod 规约中，避免设置
spec.hostNetwork: true。除非是系统级 Pod（如 CNI 插件、kube-proxy）确有需要。
- 使用 Pod 安全标准（PSP）或更新的 Pod 安全准入（PSA），在集群层面强制约束：禁止或仅允许特定服务账户使用主机网络。
- 对 DaemonSet 等系统工作负载进行专项审计，确保只有必要组件才拥有此特权。
四、构建纵深防御：不只有网络隔离
仅做网络隔离并不够。守护 kubelet 需要组合拳：认证授权、网络访问控制、TLS 强化、审计监控、运行时安全缺一不可。你是否能回答：“谁能访问 10250、访问后能做什么、做过什么、能否被及时发现？”
| 加固层面 |
具体措施 |
安全价值 |
| 认证与授权 |
1. 禁用匿名访问（--anonymous-auth=false）。 2. 强制启用 Webhook 授权模式（--authorization-mode=Webhook），使 kubelet 的 API 请求接受 kube-apiserver 的 RBAC 统一鉴权。 |
确保每一个 API 请求都有明确且经过校验的身份与权限。 |
| 网络访问控制 |
1. 使用网络策略（NetworkPolicy），在 CNI 层限制 Pod 对控制平面和节点端口的访问。 2. 在宿主机本地防火墙（如 firewalld、iptables）上，仅允许来自控制平面节点或特定管理 IP 段对 10250 端口的访问，拒绝其他一切来源。 |
实现网络层“最小权限”，即使凭证泄露，攻击路径也被阻断。 |
| TLS 强化 |
1. 使用强密码套件，定期轮换 kubelet 的服务端与客户端证书。 2. 确保 API Server 与 kubelet 之间、kubelet 与容器运行时之间的通信均为双向 TLS 认证。 |
防止通信窃听与中间人攻击。 |
| 审计与监控 |
1. 开启 kubelet 审计日志（--audit-log-path），记录所有 API 访问，尤其是对 /exec、/run 等高危端点的调用。 2. 在 SOC 监控异常访问模式，如来自非管理网段的 10250 端口连接尝试。 |
提供可追溯性，并支持实时威胁检测。 |
| 运行时安全 |
部署主机安全代理（HIDS），监测 kubelet 进程异常行为、配置文件篡改及敏感文件访问。 |
提供最后一层的运行时检测与防护。 |
总结
kubelet API 是集群工作节点的“咽喉要道”，安全性不容有失。禁用或严格管控 Pod 的宿主机网络模式，是切断一条高危内部攻击路径的有效方法，它能显著降低“容器被攻破后直接演变为节点控制”的概率。
但真正可靠的安全来自体系化落地：把强认证授权、严格网络策略、主机层防火墙、完善证书管理、持续审计监控组合起来，才能为 kubelet 构建从认证到网络、从主机到运行时的立体防护网。这也是把“最小权限原则”和“纵深防御”落实到组件级别的关键实践。 | 
发表于 昨天 18:29
|
查看: 7|
回复: 0
