4.14、云原生安全攻防：容器与 Kubernetes 的脆弱点

——从容器逃逸到集群接管的真实攻击面解析

“Kubernetes 不是不安全，而是你以为它只是个调度器。”

随着企业全面上云、微服务化加速，Kubernetes 已经成为云原生事实标准。但在攻防视角下，K8s 同时也是一个攻击面极其丰富、配置极易出错的系统。

本文将从攻击者视角出发，系统梳理云原生环境中最常见、最危险的攻击路径，并给出可落地的防御思路。

---

一、云原生安全为什么“特别危险”？

与传统主机/内网安全相比，云原生环境具备以下特征：

• 高度自动化（CI/CD、自动部署）
• 资源短生命周期（Pod 随时创建/销毁）
• 大量 API 驱动
• 权限复杂（RBAC、ServiceAccount）
• 网络边界模糊（Overlay Network）

这使得安全问题呈现出几个特点：

配置错误 ≈ 0day
一个 YAML 写错，攻击面立刻暴露

---

二、攻击者视角：典型云原生攻击链

一个真实的云原生攻击路径通常是：

应用漏洞

   ↓

容器内执行命令

   ↓

容器逃逸 / 获取宿主机权限

   ↓

访问 K8s API

   ↓

RBAC 滥用

   ↓

集群接管

下面我们逐个拆解关键脆弱点。

---

三、容器逃逸：从容器到宿主机

1️、特权容器（privileged）

如果 Pod 使用：

securityContext:

  privileged: true

攻击者在容器内即可：

• 访问宿主机设备
• 挂载宿主机文件系统
• 直接提权到 root

 实战后果：

容器 ≈ 宿主机 root

---

2️、挂载 Docker Socket

volumeMounts:

- mountPath: /var/run/docker.sock

攻击者可以：

docker run -v /:/host --privileged -it alpine chroot /host

 直接结果：
完全控制宿主机

---

3️、Linux Capability 滥用

危险 Capability 示例：

• CAP_SYS_ADMIN
• CAP_SYS_PTRACE
• CAP_NET_ADMIN

一旦赋予，攻击者可：

• 挂载文件系统
• 操作内核
• 抓取进程内存

---

防御建议（容器层）

• 禁用 privileged 容器
• 禁止挂载 docker.sock
• 严格限制 capabilities
• 使用 Pod Security Admission / PSP（旧）

---

四、Kubernetes RBAC：最常被忽视的“致命配置”

1️、ServiceAccount 权限过大

很多应用直接使用默认 SA：

serviceAccountName: default

而 default SA 却被绑定了：

cluster-admin

 攻击者在 Pod 内执行：

kubectl get secrets -A

kubectl get pods -A

kubectl create clusterrolebinding ...

➡ 集群直接沦陷

---

2️、常见 RBAC 错误示例

• 使用 * 通配权限
• 将 create/delete 权限给应用 Pod
• 将 namespace 级应用绑定 cluster 角色

---

防御建议（RBAC）

• 一个 Pod 一个 ServiceAccount
• 只授予 get/list/watch
• 禁止应用拥有 create/delete 权限
• 定期审计 RBAC

---

五、API Server 未授权访问：云上“裸奔”的入口

1️、常见暴露方式

• API Server 直接暴露公网
• 未启用身份认证
• 使用弱 Token / 过期证书

攻击者扫描到：

https://x.x.x.x:6443

即可尝试：

kubectl --server=https://x.x.x.x:6443 get pods

📌 历史上多起真实入侵案例源于此

---

2️、In-Cluster API 滥用

在 Pod 内：

cat /var/run/secrets/kubernetes.io/serviceaccount/token

即可访问 API：

curl https://kubernetes.default.svc

若 RBAC 配置错误 → 横向 & 提权

---

防御建议（API 层）

• API Server 不暴露公网
• 强制 TLS + 认证
• 配合 OIDC / MFA
• 开启审计日志

---

六、云原生特有攻击面（容易被忽视）

1️、镜像投毒（Supply Chain Attack）

• 使用不可信公共镜像
• CI/CD 中镜像被篡改
• 镜像中自带后门

 防御：

• 镜像签名（Cosign）
• 私有镜像仓库
• 镜像安全扫描

---

2️、Namespace 并非安全边界

• 默认网络互通
• Secret 可被误授权访问

 防御：

• NetworkPolicy
• Secret 精细化授权

---

七、云原生安全防御体系（推荐组合）

1️、运行时防护

• Falco（行为检测）
• eBPF-based Runtime Security

2️、配置安全

• kube-bench
• kube-hunter
• Trivy

3️、身份与访问控制

• RBAC 最小化
• ServiceAccount 独立
• OIDC + SSO

4️、审计与可观测性

• K8s Audit Log
• 集成 SIEM
• 异常行为告警

---

八、攻防视角总结

攻击点	本质问题	防御核心
容器逃逸	权限过大	最小权限
RBAC 滥用	身份不清	细粒度授权
API 暴露	边界模糊	身份认证
镜像投毒	供应链风险	镜像可信

---

结语：Kubernetes 是“控制平面”，不是“安全平面”

云原生环境中，攻击者并不需要 0day，
他们只需要：

• 一个写错的 YAML
• 一个默认的 ServiceAccount
• 一个暴露的 API Server

安全必须成为集群设计的一部分，而不是部署后的补丁。