Kubernetes 渗透测试方法论：从攻击者视角看集群安全
发布: (2026年1月30日 GMT+8 23:38)
6 分钟阅读
原文: Dev.to
Source: Dev.to
概览
截至 2026 年，Kubernetes 已成为基础设施的事实标准，攻击者的技术也变得更加成熟。像 “Dashboard 对所有人开放” 这样的简单失误已经很少见；相反，我们看到利用以下方面的攻击在增加：
- RBAC 复杂性
- 短期令牌滥用
- 供应链薄弱环节
本文概述了一套现代 Kubernetes 渗透测试方法论，分为三个阶段：
- RBAC 配置错误 – 通过绑定的令牌进行特权提升
- 远程攻击 – 外部入侵向量和供应链威胁
- 内部威胁 – 容器逃逸和云元数据攻击
1. RBAC 配置错误 – 权限的陷阱
自 Kubernetes v1.24 起，基于 secret 的持久化 ServiceAccount 令牌不再自动生成。绑定的 Service Account 令牌（投影卷） 现在成为默认方式。虽然这提升了安全性，但 “pod 创建” 权限仍然危险。
攻击场景：利用短期令牌进行特权提升
攻击者创建一个挂载了特权 ServiceAccount 的 pod，然后在 pod 内调用 TokenRequest API 获取持久化使用的令牌。
关键检查项
| 权限 / 资源 | 需要验证的内容 |
|---|---|
create pods/ephemeralcontainers | 用户是否能够创建特权 pod 以进行特权提升？ |
impersonate | 用户是否有冒充其他用户或组的权限？ |
bind / escalate（角色） | 用户是否能够创建 RoleBinding 来提升自身权限？ |
| 旧版 secret 残留 | 是否仍然存在不自动过期的静态 ServiceAccount 令牌 Secret？ |
2. 远程攻击 – 外部入侵
For black‑box testing, attackers look beyond API‑server misconfigurations to weaknesses in development tools and the supply chain.
主要攻击向量
| 组件 | 常见错误配置 |
|---|---|
| API 服务器（端口 6443） | system:anonymous 拥有任何权限 – 在测试环境中常见。 |
| Kubelet API（端口 10250） | --anonymous-auth=true 已启用，允许通过 run 执行任意代码。 |
| 外围工具 | 管理界面（ArgoCD、Prometheus、Kubernetes Dashboard）暴露在互联网。 |
| 供应链 | kubeconfig 文件或 CI/CD 凭证在公共仓库中泄露。 |
3. 内部威胁 – 来自内部的威胁
当攻击者在灰盒测试期间通过（例如 Web‑app RCE）在 pod 内获得立足点时，下一步目标是 节点逃逸。
内部侦察检查清单
| 指标 | 为什么重要 |
|---|---|
特权容器 (privileged: true 或 CAP_SYS_ADMIN) | 授予对宿主设备的完整访问权限。 |
容器套接字挂载 (/var/run/docker.sock 或 /run/containerd/containerd.sock) | 允许攻击者在宿主机上启动任意容器。 |
| 内核 / 运行时漏洞 | 可利用的宿主操作系统内核或容器运行时（例如 runc）中的漏洞。 |
| 云元数据服务（AWS IMDSv2、GCP 元数据） | 如果可访问，攻击者可以窃取节点的 IAM 角色或服务账户凭证。 |
摘要 – 现代防御的重要性
在 2026 年，攻击者不再仅依赖简单的端口扫描；他们熟练掌握 Kubernetes 内部机制（RBAC、令牌、准入控制器）。防御者必须采用分层防御方法：
- Validating Admission Policy (VAP) – 阻止特权 Pod 的创建，禁止令牌请求滥用，强制最小权限 RBAC。
- Continuous Auditing – 定期扫描遗留的密钥、暴露的端点以及配置错误的 kubelet。
- Supply‑Chain Hygiene – 轮换
kubeconfig凭证，扫描公共仓库以发现泄漏，并执行密钥管理策略。 - Runtime Hardening – 禁用匿名访问，限制套接字挂载，并保持主机操作系统 / 运行时的最新补丁。
通过整合这些控制措施，团队能够在不断演变的威胁环境中保持领先，使其 Kubernetes 集群能够抵御外部和内部攻击，保持弹性。
Kubernetes 安全最佳实践
Pod 安全
- 特权 Pod：使用 CEL（通用表达式语言）进行原生策略管理，以在特权 Pod 上强制执行安全约束。
最小特权
- 仅授予
ServiceAccount所需的最小权限。 - 在 Pod 规范中默认使用
automountServiceAccountToken: false：
apiVersion: v1
kind: Pod
metadata:
name: example-pod
spec:
automountServiceAccountToken: false
# ... other pod spec fields ...运行时安全
- 部署基于 eBPF 的工具，如 Tetragon 或 Falco，实时监控和检测异常系统调用和进程启动。
持续安全流程
- 将 Kubernetes 安全视为一个持续的、不断进行的过程，而不是一次性的配置任务。
- 定期进行渗透测试和配置审计，以保持强大的安全姿态并保护集群。