文章总结： 本文深入解析Kubernetes关键组件kubeletAPI的安全风险与防护实战。文章指出kubelet运行在宿主机并监听10250端口，若Pod开启hostNetwork或配置不当，攻击者可利用高危接口控制节点。建议实施纵深防御，包括禁用匿名访问、启用Webhook授权、严格限制hostNetwork、配置网络策略与防火墙，并强化TLS及审计监控，构建立体安全体系以阻断攻击路径。 综合评分： 90 文章分类： 云安全,安全建设,内网渗透

穿透Kubernetes节点安全：深度解析kubelet API与防护实战

原创

Hash先生

倬其安

2026年1月7日 00:01 福建

#

#

在Kubernetes集群中，有一个关键组件管理着每个节点的“生杀大权”，却也往往成为攻击者最想控制的突破口。

当您查看Kubernetes集群的安全态势时，有一个组件的安全性至关重要却常被忽视——它运行在每个计算节点上，手握创建容器、挂载存储、执行命令的实权，却可能因为配置不当而门户大开。这就是kubelet API。

一、kubelet API：每个节点上的“行政主管”

想象一下，Kubernetes控制平面（如kube-apiserver）是公司的“总部董事会”，负责制定战略和发布指令。而每个工作节点就是一家独立运营的分公司。kubelet，就是这家分公司的行政主管。

1. 它是什么？kubelet是运行在每个工作节点（物理机或虚拟机）上的代理程序。它的核心职责是接收来自“总部”（控制平面）的指令，并确保本节点上的Pod（容器组）按预期运行。而kubelet API，就是这位主管对外沟通的“工作电话”和“命令执行窗口”。
2. 它部署在哪里？它直接部署并运行在每个工作节点的宿主机操作系统上，通常以系统服务（如systemd服务）的形式存在。这意味着，它不在容器内部，而是与宿主机共享内核和网络命名空间，拥有极高的本地权限。
3. 它的工作原理是怎样的？kubelet持续监听来自两方面的指令：

• 来自“总部”的命令：它主动连接kube-apiserver，接收关于“本节点应该运行哪些Pod”的清单（PodSpec）。
• 处理外部直接请求：它同时开启一个HTTPS服务端（默认端口10250），这就是kubelet API。通过这个API，不仅可以查询节点和Pod的状态，更重要的是，它可以执行容器内命令、获取容器日志、甚至进行端口转发。

二、敏感端口：为什么10250端口如此危险

默认情况下，kubelet API服务在所有网络接口（0.0.0.0） 的10250端口上监听。这带来了巨大的安全暴露面：

1. 高危操作暴露：

• /exec：可以在运行的容器中执行任意命令。
• /run：可以启动新容器。
• /logs：可以抓取所有容器日志，可能包含敏感信息。
• /portForward：可以建立到容器的网络隧道。

1. 认证与授权薄弱环节： 在早期或配置不当的集群中，kubelet可能启用匿名访问，或仅依赖较弱的客户端证书认证。一旦攻击者能访问该端口，就可能直接控制节点上的所有Pod，进而窃取数据、植入后门或横向移动。

三、关键加固：用宿主机网络隔离降低暴露面

直接回答您最核心的问题：是的，将Pod配置为不使用宿主机网络，是降低kubelet API（10250端口）暴露风险的关键且有效的一环。 但这只是“一环”，需要系统性地理解。

攻击路径假设：如果攻击者成功在一个Pod内（例如，通过应用漏洞实现了容器逃逸），而该Pod又共享了宿主机的网络命名空间（hostNetwork: true），那么攻击者从容器内部就能直接访问到宿主机本地回环地址（127.0.0.1）的10250端口，绕过了所有外部的网络防火墙策略。

防护措施：禁用或严格控制hostNetwork：

1. 原理：通过确保业务Pod运行在独立的Pod网络命名空间中（这是默认的、理想的状态），即使容器被攻破，攻击者也无法直接访问宿主机本地的敏感管理端口（包括10250、10255等）。他们被困在独立的Pod网络沙箱中。
2. 实施：

• **在Pod规约中，避免设置spec.hostNetwork: true**。除非是系统级Pod（如CNI插件、kube-proxy）确有需要。
• 使用Pod安全标准（PSP）或更新的Pod安全准入（PSA），在集群层面强制约束，禁止或仅允许特定服务账户使用主机网络。
• 对DaemonSet等系统工作负载进行专项审计，确保只有必要的组件才拥有此特权。

四、构建纵深防御：不只有网络隔离

仅仅隔离网络是不够的。守护kubelet需要一套组合拳，在架构上贯彻纵深防御原则：

| 加固层面 | 具体措施 | 安全价值 | | — | — | — | | 认证与授权 | 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构建从认证到网络、从主机到运行时的立体防护网。在金融级云平台中，这正是将“最小权限原则”和“纵深防御”理念，落实到每一个具体组件的生动实践。

关注「倬其安」，构建金融级云原生安全纵深

我们专注于金融科技领域的一线安全实践，从架构设计到组件加固，为您提供透彻、可落地的安全解读与方案。

如果您正面临云原生环境的安全挑战，或想了解如何系统性地构建Kubernetes安全体系，关注我们，与众多同行一起，筑牢数字金融的底层安全防线。

![](https://mmbiz.qpic.cn/mmbiz_png/5GBRKfKXqpv3UEdyCDhgj2ic0QiclGDzdWASGcLAG8Fzl9ibicVC64tSKz3I4kg4dBg3WiaurszKZlzT3I0mYHVMaJA/640?wx_fmt=png#imgIndex=0)![](https://mmbiz.qpic.cn/mmbiz_jpg/cuBApO3XWpSMbPO4BjnKvkIZ6IdfXjJX7b5cqBz79XDB8aLttiaOicXh80qALicmgia6F2dvxTWBWia3ic4govxibVWXA/640?wx_fmt=jpeg&watermark=1#imgIndex=1)

「倬其安」分享一线实战中的故障洞察与架构思考。

提升安全认知，筑牢防护体系！

“倬其安，然无恙”。

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：倬其安 Hash先生《穿透Kubernetes节点安全：深度解析kubelet API与防护实战》