Kubernetes 集群未授权访问漏洞分析与容器逃逸横向移动

Kubernetes（K8s）是当前主流的容器编排平台，一旦集群入口或节点组件配置不当，攻击者可能从“未授权访问”一路到“容器逃逸”“横向移动”最终接管整个集群。本文不从攻击操作的角度展开，而是先把 K8s 的关键架构讲清楚，再以防御为中心：分析几类典型配置缺陷的成因与危害，并给出对应的加固、检测与缓解建议，帮助安全人员理解“为什么会被打穿”以及“应该在哪几道防线拦截”。

一、前置知识：K8s 架构与安全相关的关键面

理解风险的前提是理解集群里“谁是入口、谁存敏感数据、谁有特权”。

控制平面

• API Server：集群唯一入口，所有操作都经 REST API，需经过“认证→授权→准入控制”三步。默认安全端口 6443（HTTPS）。
• etcd：集群的“数据库”，存储所有敏感信息（Pod 配置、ServiceAccount Token、Secret、集群状态），是核心数据底座。客户端 API 端口 2379、集群对等同步端口 2380。
• Scheduler / Controller Manager：负责调度与副本/节点状态维持，与直接安全暴露面关系较小。

节点组件

• Kubelet：节点“管家”，对外提供 10250（HTTPS，默认需认证）与 10255（HTTP 只读，默认关闭）两个端口，负责容器生命周期与指令执行。
• Kube-proxy：维护节点网络转发规则，实现 Service 负载均衡。
• 容器运行时：真正跑容器的组件（containerd、CRI-O 等）。

与安全强相关的资源对象

• Pod / Deployment：最小部署单元与其控制器。需特别警惕 securityContext.privileged（特权模式）与将宿主机目录作为 Volume 挂载的配置。
• Service：ClusterIP（仅集群内）、NodePort（暴露节点端口）、LoadBalancer（对接云厂商）。对外端口暴露面直接由此决定。
• ServiceAccount 与 Token：Pod 访问集群的身份凭证，Token 以 Secret 形式存在并默认挂载到 Pod 内固定目录；通过 RBAC 绑定权限，一旦绑定 cluster-admin 就拥有集群最高权限。
• Secret / ConfigMap：分别存敏感与非敏感配置，Secret 仅做 base64 编码，不等于加密。
• Namespace / RBAC / NetworkPolicy：集群隔离与访问控制的主体。

一句话概括攻击面的本质：入口组件的认证/授权被关掉、数据底座 etcd 不设防、容器拥有过多特权、高权限凭证在 Pod 内可被轻易读取——这四者串联就构成从外部到集群接管的路径。下面逐面分析防御要点。

二、Kubelet 未授权访问：成因与加固

成因。 Kubelet 未授权访问的本质是认证/授权配置不当：当 anonymous.enabled: true 开启匿名访问、且授权策略为 AlwaysAllow 时，10250 等端口就不对请求做任何认证鉴权，未授权主体可直接调用其 API，窃取集群信息、在容器中执行命令甚至控制节点。

加固与检测。

• 关闭匿名认证，将授权模式改为 Webhook（走集群 RBAC），不要使用 AlwaysAllow；kubelet 配置变更后需重启生效。
• 10250 强制 TLS 与客户端证书认证；10255 只读端口保持默认关闭。
• 通过网络策略/主机防火墙限制 10250/10255 的可达范围，仅允许控制平面等可信来源访问，绝不暴露到公网。
• 定期扫描节点上 kubelet 配置是否意外开启了匿名访问/只读端口，作为基线合规项。

三、etcd 未授权访问：成因与加固

成因。 etcd 保存了整个集群状态，包括所有 Secrets（数据库密码、API 令牌、TLS 私钥、仓库密码等）、ConfigMap、Pod/Service/Deployment 定义、ServiceAccount 令牌与网络策略。若部署 etcd 时未开启证书认证且 2379 直接对外开放，就会形成未授权访问：攻击者可直读 Secret、篡改资源定义（如把正常 Pod 镜像换成恶意镜像、部署挂载主机路径的特权 Pod）、修改 RBAC/网络策略，为后续渗透铺平道路。

加固与检测。

• 强制启用 etcd 的证书认证与客户端认证（TLS），禁止明文对外。
• 2379/2380 仅绑定内网/回环，通过防火墙限制访问源，绝不可路由到公网。
• 对 etcd 中的静态数据启用加密（encryption provider），降低“即使读到也难解”的风险。
• 将 etcd 备份与访问纳入审计，监控异常的连接与大量键读取行为。

四、API Server 未授权：成因与加固

成因。 API Server 未授权是“认证环节失效或授权环节完全放行”的组合：

• --anonymous-auth=true 使无任何凭证的请求以匿名用户身份进入，跳过验证；
• --authorization-mode=AlwaysAllow（默认应为 Node,RBAC）使所有请求无论身份都被放行；
• 低版本若开启 --insecure-port（如 8080）且 --insecure-bind-address=0.0.0.0，相当于启用了一个“无加密、无强制认证”且全网监听的入口，无需处理证书与凭证即可与 API Server 通信。

加固与检测。

• 关闭匿名认证；授权模式固定为 Node,RBAC（必要时叠加 Webhook），严禁 AlwaysAllow。
• 废弃不安全端口（--insecure-port=0），仅保留需 TLS 与凭证的 6443；绑定地址收敛到具体内网地址而非 0.0.0.0。
• 通过审计日志记录 API Server 的异常匿名/高权限请求，并定期核查 apiserver 启动参数。

五、容器逃逸：特权模式与主机挂载的成因与缓解

成因。 容器逃逸多源于容器被赋予了不应有的主机能力：

• 特权容器（privileged: true）使容器内 root 实际上获得接近宿主机 root 的能力，可访问主机设备、尝试挂载宿主文件系统；
• 将宿主机目录/敏感路径挂载进容器（如根目录、/proc、kubelet 相关目录）直接为改写主机提供了通道；
• 危险 Linux Capabilities 未收敛、hostPID/hostNetwork/hostIPC 滥用，都会扩大逃逸面。逃逸后常见持久化手法包括写入计划任务、植入 SSH 公钥等。

加固与缓解。

• 默认禁止特权容器，通过 Pod Security Admission（restricted 等级）限制 privileged、主机命名空间与主机路径挂载；仅对确实需要的系统组件例外放行。
• drop 不必要的 capabilities，以非 root 用户运行，启用 readOnlyRootFilesystem，限制 seccomp/AppArmor/SELinux。
• 使用安全运行时（如 gVisor/Kata 类沙箱）隔离内核面；避免将宿主敏感路径作为 Volume。
• 运行时检测：关注容器内挂载宿主文件系统、异常计划任务/authorized_keys 变更、可疑进程向宿主机命名空间迁移等行为，纳入 EDR/运行时安全监控。

六、高权限凭证与 ServiceAccount：成因与缓解

成因。 Pod 内部可能存有高权限 ServiceAccount：默认情况下每个命名空间有一个权限极低的 default SA，但管理员若创建了绑定 cluster-admin 的自定义 SA，K8s 会将其 JWT Token 默认挂载到 Pod 内固定目录；一旦攻击者进入该 Pod 即可直接读取，用它向 API Server 发起管理员级操作、完全掌控集群。此外节点上的 kubeconfig（如 kubelet 凭证）若被窃取同样危险。

加固与缓解。

• 遵循最小权限：避免将 cluster-admin 绑定到业务 SA；用细分的 Role/ClusterRole 按需授权。
• 对不需要访问 API Server 的 Pod 设置 automountServiceAccountToken: false，避免高权限 Token 无谓落盘。
• 启用 Bound ServiceAccount Token（缩短有效期、绑定 Pod），降低 Token 被盗后的可用窗口。
• 保护与审计节点上的 kubeconfig 等凭证文件，避免将其打包进镜像或写入日志。

七、横向移动：利用调度机制上线主节点

成因。 拿到高权限 Token 后，攻击者可能利用污点与容忍（Taint/Toleration）机制，在通常被隔离的主节点上以“容忍”配置部署一个可逃逸的恶意 Pod，再重复特权挂载方式逃逸到主节点，完成横向移动；若权限足够但目标节点无相应污点，甚至可能反向创建污点驱逐正常负载。

加固与检测。

• 严格控制“谁能创建/修改 Pod”的 RBAC，尤其是具备 cluster-admin 或可部署特权工作负载的主体。
• 为主节点设置合理污点并审计异常容忍；监控在非业务节点（如控制平面）上突然出现的新 Pod。
• 启用准入控制（如 Pod Security、镜像验签/白名单、OPA/Kyverno 类策略），阻断不合规工作负载的创建。

八、通用纵深防御清单

1. 入口收敛：API Server、kubelet、etcd 均强制 TLS + 真实认证/授权；关闭匿名、不安全端口与只读端口，监听地址与访问源最小化。
2. 工作负载安全：禁用特权与主机命名空间，收敛 capabilities，非 root 运行，只读根文件系统，不挂载宿主敏感路径。
3. 权限与凭证：RBAC 最小化、慎用 cluster-admin，不自动挂载 SA Token，启用绑定型短期 Token，加密 etcd 静态数据。
4. 准入与策略：Pod Security Admission、镜像验签/白名单、策略引擎（OPA/Kyverno）拦截不合规配置。
5. 可观测与审计：开启 API Server/etcd/kubelet 审计日志，部署运行时安全监控，对异常命令执行、容器逃逸特征、可疑 Pod 调度告警。
6. 定期体检：将“是否存在未授权 kubelet/etcd/apiserver、是否有特权容器、是否有高权限 SA”作为常态化安全基线逐项排查。

小结

从“未授权访问”到“容器逃逸”再到“横向移动”，K8s 集群被接管的链条本质上是一条配置缺陷的叠加链：入口不设防、数据底座不加密不认证、容器过权、凭证易得。防御也恰好沿着这条链展开——把认证/授权真正打开、把端口与访问面收敛、把容器权限降到最小、把凭证与 RBAC 管严、把审计与运行时检测补齐，就能在多个环节阻断同一类攻击路径。

本文内容仅用于安全研究、架构加固与防护检测之目的。所有测试与验证均应在授权范围内、于自有或隔离环境中开展，遵守《中华人民共和国网络安全法》及相关法律法规，不得用于任何未经授权的入侵行为。