什么是Kubernetes未认证扫描？

想象一下，你面前有一栋戒备森严的数据中心大楼，里面运行着至关重要的Kubernetes集群。大门紧锁，需要身份卡和密码才能进入。但如果你发现，大楼侧面有一扇窗户没关严，甚至后门根本没锁，你会怎么做？对于安全人员而言，这就是“未认证扫描”开始的地方。

本质：在不敲门的情况下试探门锁

Kubernetes未认证扫描，说白了，就是一种在无需提供任何身份凭证（如令牌、证书或用户名密码）的情况下，对Kubernetes API Server或其他服务端点进行的探测与信息收集。它不试图“破解”密码，而是寻找那些压根就没设密码的入口。

这听起来像是一种“黑客行为”，但在安全领域，它的正式身份是“外部攻击面评估”或“配置错误审计”。其核心逻辑在于，许多Kubernetes集群在部署时，可能因为运维疏忽、默认配置不当或对云服务商安全模型理解不足，意外暴露了本应受保护的接口。

那些敞开的“后门”通常长什么样？

• 匿名访问被启用：最典型的情况。Kubernetes API Server的--anonymous-auth参数被设置为true（在某些旧版本或特定配置下甚至是默认值），允许未经任何认证的请求执行某些只读操作。
• 不当的网络策略与防火墙规则：也许API Server本身配置正确，但承载它的节点或云安全组规则过于宽松。例如，将控制平面的6443端口或只读端口8080直接暴露在公网，且未配置任何网络层访问控制列表（ACL）。
• kubelet的“开放门户”：每个工作节点上的kubelet服务，其只读端口（默认10255）或读写端口（默认10250）如果未正确配置TLS或认证，就可能成为信息泄露甚至远程代码执行的跳板。
• 云服务商的“托管”误解：使用EKS、AKS、GKE时，用户可能误以为所有安全都由平台负责，而忽略了检查自己配置的集群网络访问策略，导致控制平面端点对0.0.0.0/0开放。

扫描器在“看”什么？

一次未认证扫描远不止是ping通一个端口那么简单。专业的扫描工具（如Kubestriker、kube-hunter等）会执行一系列结构化的探测，旨在绘制出一张清晰的“攻击地图”：

• 服务发现：识别所有开放的、与Kubernetes相关的端口和服务。
• API路径枚举：尝试访问/api、/apis、/version、/healthz等标准路径，从返回信息中获取Kubernetes版本、API资源列表等敏感元数据。一个版本号泄露，就可能让攻击者精准利用已知漏洞。
• 资源信息提取：如果匿名访问权限较高，扫描器可能会尝试列出节点（Nodes）、命名空间（Namespaces）、Pod甚至Secrets（如果配置极其错误）的信息。获取到的Pod名称、标签、所在节点信息，都是后续攻击极有价值的铺垫。
• 权限试探：通过尝试执行某些特定的API请求，来探测匿名用户实际拥有的权限边界，判断是纯信息泄露，还是存在更危险的写入可能。

为什么这比数据泄露本身更危险？

未认证扫描发现的往往不是最终漏洞，而是攻击链的完美起点。它带来的风险是系统性的：

首先，它极大地降低了攻击门槛。攻击者无需窃取凭证或利用复杂的认证绕过漏洞，直接从“零权限”升级到“有立足点”。其次，暴露的集群信息为后续的精准攻击提供了蓝图。知道了版本，就可以搜索公开漏洞；知道了节点和Pod分布，就能规划横向移动路径。

更令人担忧的是，这种配置错误通常意味着更深层次的安全文化缺失。能犯下“把后门敞开”这种错误的部署流程，很可能在其他安全环节，如镜像安全、网络策略、权限管理上也存在疏漏。

防御视角：关上那扇窗

对于防御方，理解未认证扫描的价值在于主动自我审视。定期从外部网络视角对自己的Kubernetes集群执行未认证扫描，应该成为安全基线的标配动作。具体措施包括：

• 确保API Server的--anonymous-auth=false。
• 严格配置网络策略，确保控制平面端点不直接暴露于公网，或仅对可信IP范围开放。
• 安全配置kubelet，禁用非安全端口，对10250端口强制使用客户端证书认证。
• 在云托管环境中，充分利用并正确配置平台提供的私有集群、授权网络（Authorized Networks）或VPC端点（VPC Endpoint）功能。
• 部署服务网格或API网关，为所有入口流量增加一层统一的认证和授权。

安全从来不是一堵密不透风的墙，而是一扇需要时刻确认是否关好的门。未认证扫描就是那个提醒你检查门锁的、最直接的警报声。在攻击者用它来窥探之前，自己先听一听。