2026 年，某知名电商公司的 K8s 集群在凌晨 3 点被攻破，攻击者通过一个配置错误的 kubelet 接口拿到节点权限，然后横向移动到控制平面，最终窃取了整个生产环境的数据库凭证。

这不是个例。根据 Aqua Security 发布的《2026 年云原生安全报告》，83% 的组织在过去 12 个月内经历过至少一次 K8s 安全事件，而其中67% 的事故源于配置错误，而非 0day 漏洞。

我花了 2 周时间，复盘了 20+ 个真实 K8s 安全事件（来源：公开漏洞报告、SRC 案例、安全社区分享），整理出攻击者最常用的 5 个入口，并附上对应的防御检查清单。

如果你负责 K8s 集群运维，建议收藏这篇，逐项对照检查。

【5 个常见攻击入口】

入口 1：未授权的 kubelet 访问 ⚠️

风险等级：�� 高危

攻击原理：

kubelet 是 K8s 节点上的核心组件，默认监听 10250 端口。如果未启用认证授权，攻击者可以直接：
• 执行任意容器命令
• 读取 Pod 日志和配置文件
• 访问节点文件系统
• 提权到宿主机

真实案例：

2025 年某云服务商用户集群被挖矿，攻击者扫描全网 10250 端口，发现未授权的 kubelet 后，通过 /exec 接口在容器内执行挖矿脚本。

检测命令：

# 检查 kubelet 是否开放未授权访问
curl -k https://<node-ip>:10250/pods

# 如果返回 Pod 列表，说明存在风险

防御清单：

☐ 启用 kubelet 认证（--authentication-token-webhook=true）
☐ 启用 kubelet 授权（--authorization-mode=Webhook）
☐ 限制 kubelet 端口访问（防火墙/安全组）
☐ 使用 RBAC 限制 Pod 访问权限
☐ 定期扫描暴露的 10250 端口

入口 2：容器逃逸 ��

风险等级：�� 高危

攻击原理：

攻击者通过漏洞或配置错误，从容器内突破到宿主机，常见方式：
• 特权容器（privileged: true）
• 挂载宿主机敏感目录（/proc、/sys、/）
• 内核漏洞（如 Dirty Pipe、runc 漏洞）
• 不安全的 Capability 配置

真实案例：

某金融公司 K8s 集群中，一个调试容器配置了 privileged: true，攻击者通过 Web 漏洞进入该容器后，直接挂载宿主机根目录，拿到 root 权限。

检测命令：

# 检查特权容器
kubectl get pods --all-namespaces -o jsonpath='{range .items[*]}{.metadata.namespace}{"\t"}{.metadata.name}{"\t"}{.spec.containers[*].securityContext.privileged}{"\n"}{end}' | grep true

# 检查敏感挂载
kubectl get pods --all-namespaces -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.spec.volumes[*].hostPath.path}{"\n"}{end}'

防御清单：

☐ 禁止使用特权容器（除非绝对必要）
☐ 限制 hostPath 挂载，禁止挂载 /、/etc、/proc
☐ 使用 PodSecurityPolicy 或 Pod Security Admission
☐ 定期更新 containerd/runc 到最新版本
☐ 使用只读根文件系统（readOnlyRootFilesystem: true）
☐ 移除不必要的 Linux Capabilities

入口 3：敏感信息泄露 ��

风险等级：�� 中高危

攻击原理：

K8s 中存储的 Secret、ConfigMap、环境变量可能包含：
• 数据库密码
• API 密钥
• 云服务凭证
• SSH 私钥

攻击者一旦进入集群，可以通过多种方式获取：

# 读取所有 Secret
kubectl get secrets --all-namespaces -o yaml

# 读取 Pod 环境变量
kubectl exec <pod> -- env

# 访问 ServiceAccount Token
cat /var/run/secrets/kubernetes.io/serviceaccount/token

真实案例：

某初创公司把 AWS Access Key 放在 Deployment 的环境变量中，攻击者通过 SSRF 漏洞访问到 K8s API 后，窃取凭证并访问了 AWS 资源，损失约 50 万元。

防御清单：

☐ 使用外部密钥管理（如 HashiCorp Vault、AWS Secrets Manager）
☐ 启用 Secret 加密（EncryptionConfiguration）
☐ 限制 ServiceAccount 权限（最小化 RBAC）
☐ 定期轮换密钥和凭证
☐ 禁止在代码/镜像中硬编码敏感信息
☐ 使用 OPA Gatekeeper 审计敏感配置

入口 4：网络策略缺失 ��

风险等级：�� 中危

攻击原理：

K8s 默认允许所有 Pod 之间互相访问。攻击者突破一个 Pod 后，可以：
• 横向移动到数据库 Pod
• 访问内部 API 服务
• 扫描内网其他服务
• 发起 SSRF 攻击

真实案例：

某电商平台被攻破，攻击者从前端 Pod 进入后，直接访问了后端数据库 Pod（无网络隔离），拖走 100 万 + 用户数据。

防御清单：

☐ 启用网络策略（Calico、Cilium、Flannel）
☐ 默认拒绝所有流量（Default Deny）
☐ 按 Namespace 隔离不同环境（prod/dev/test）
☐ 限制 Pod 出向流量（防止数据外传）
☐ 使用 NetworkPolicy 限制 Pod 间通信
☐ 定期审计网络策略配置

入口 5：RBAC 配置不当 ��

风险等级：�� 中危

攻击原理：

RBAC（基于角色的访问控制）配置过宽时，攻击者可以：
• 创建特权 Pod
• 访问其他 Namespace 资源
• 修改 Deployment/StatefulSet
• 提升 ServiceAccount 权限

常见错误配置：

# ❌ 危险：授予 cluster-admin 权限
roleRef:
  kind: ClusterRole
  name: cluster-admin

# ❌ 危险：允许创建任意 Pod
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["*"]

防御清单：

☐ 遵循最小权限原则
☐ 避免使用 cluster-admin（除非必要）
☐ 按 Namespace 划分权限
☐ 定期审计 RBAC 配置
☐ 使用工具检查过度授权（如 rbac-lookup、kubectl-who-can）
☐ 限制 Pod 创建权限（防止特权容器）

【实践建议】

1. 立即检查清单（1 小时内完成）

# 1. 扫描暴露的 kubelet 端口
nmap -p 10250 <node-ip>

# 2. 检查特权容器
kubectl get pods --all-namespaces -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.spec.containers[*].securityContext.privileged}{"\n"}{end}' | grep true

# 3. 查看 cluster-admin 绑定
kubectl get clusterrolebindings -o jsonpath='{range .items[?(@.roleRef.name=="cluster-admin")]}{.metadata.name}{"\n"}{end}'

2. 中期加固（1 周内完成）

• 启用网络策略（Default Deny）
• 配置 Secret 加密
• 部署 Pod Security Admission
• 建立 RBAC 审计流程

3. 长期建设（持续）

• 集成安全扫描到 CI/CD（如 Kubesec、Checkov）
• 部署运行时安全监控（如 Falco）
• 建立 K8s 安全基线
• 定期红队演练

【工具推荐】

工具	用途	地址
kube-bench	CIS K8s 基线检查	https://github.com/aquasecurity/kube-bench
Kubesec	Pod 安全扫描	https://kubesec.io/
Checkov	IaC 安全扫描	https://www.checkov.io/
Falco	运行时安全监控	https://falco.org/
rbac-lookup	RBAC 权限审计	https://github.com/FairwindsOps/rbac-lookup

【总结】

K8s 安全不是单一工具能解决的，而是需要纵深防御：

1️⃣ 边界防护：限制 kubelet、API Server 访问
2️⃣ 容器加固：禁止特权、限制挂载
3️⃣ 网络安全：NetworkPolicy 隔离
4️⃣ 权限管控：RBAC 最小化
5️⃣ 持续监控：运行时检测异常

安全是一个过程，不是一个状态。建议你对照这份清单，逐项检查自己的 K8s 集群。