mobile wallpaper 1mobile wallpaper 2mobile wallpaper 3mobile wallpaper 4
Profile Image of the Author
Souloss
公告
欢迎来到我的博客！这是一条示例公告
标签
3003 字
8 分钟
容器与Kubernetes安全：从共享内核到容器逃逸的攻防全景
2025-02-21
云安全攻防技术
Kubernetes
/
安全
/
云安全
/
容器

2024年2月，安全研究员在runc中发现了三个容器逃逸漏洞——统称”Leaky Vessels”。其中CVE-2024-21626允许攻击者通过/proc/self/cwd符号链接将容器内的工作目录指向宿主机文件系统，从而突破容器边界。这不是理论推演——runc是几乎所有容器运行时的底层组件，Docker、containerd、Kubernetes全部受影响。

更令人不安的是，这个漏洞的根因是容器安全模型的一个根本性假设：容器通过Namespace和cgroup实现隔离，但共享宿主机内核。只要内核暴露了任何可被利用的接口，容器的隔离边界就可能被突破。

本文将从容器安全模型的前置知识出发，分析容器逃逸的六大路径，深入Kubernetes的攻击面，并构建容器与K8s的纵深防御体系。

一、前置知识：容器隔离模型与信任边界#

1.1 容器不是虚拟机#

这是理解容器安全最重要的前提：

graph TB subgraph "虚拟机（强隔离）" A1["App"] --> B1["Guest OS<br/>独立内核"] B1 --> C1["Hypervisor<br/>硬件级隔离"] C1 --> D1["Host OS"] end subgraph "容器（共享内核）" A2["App"] --> B2["Container Runtime<br/>Namespace + cgroup"] B2 --> C2["Host Kernel<br/>共享内核"] C2 --> D2["Host OS"] end style C1 fill:#90EE90 style C2 fill:#FF6B6B

虚拟机通过Hypervisor实现硬件级隔离——每个VM有独立的内核，攻击者需要突破Hypervisor才能逃逸。容器通过Linux Namespace和cgroup实现进程级隔离——所有容器共享宿主机内核，攻击者只需要找到一个内核接口的漏洞就能突破隔离。

隔离维度虚拟机容器
内核独立Guest OS内核共享Host内核
隔离机制硬件虚拟化(VT-x/AMD-V)Namespace + cgroup + Seccomp
逃逸难度需突破Hypervisor需突破Namespace（内核漏洞即可）
攻击面Hypervisor接口整个Linux内核
资源开销高（完整OS）低（共享内核）

核心矛盾：容器的优势（轻量、共享内核）正是其安全劣势的根源。

1.2 Linux Namespace与cgroup#

容器隔离的两大支柱：

container_isolation:
  # Namespace：资源可见性隔离
  namespaces:
    - PID: "进程ID隔离——容器内PID 1在宿主机是另一个PID"
    - Mount: "文件系统挂载隔离——容器看不到宿主机的挂载点"
    - Network: "网络栈隔离——容器有独立的网络接口和路由表"
    - User: "用户ID映射——容器内root映射到宿主机非特权用户"
    - UTS: "主机名隔离"
    - IPC: "进程间通信隔离"


  # cgroup：资源使用限制
  cgroups:
    - CPU: "限制CPU使用量"
    - Memory: "限制内存使用量"
    - PIDs: "限制进程数量"
    - Network: "限制网络带宽"
    - Devices: "限制可访问的设备"


  # Seccomp：系统调用过滤
  seccomp:
    - "限制容器可调用的系统调用"
    - "默认配置已阻止约44个危险系统调用"
    - "但允许约300+系统调用——攻击面仍然很大"

Namespace提供”看不见”的隔离，cgroup提供”用不了”的限制，Seccomp提供”调不了”的过滤。三者组合构成了容器的安全边界——但这个边界比虚拟机薄得多。

1.3 容器运行时安全模型#

graph TB subgraph "容器安全边界" A["应用进程"] --> B["Namespace隔离"] B --> C["cgroup限制"] C --> D["Seccomp过滤"] D --> E["Capability约束"] E --> F["共享内核"] end subgraph "逃逸路径" G["内核漏洞"] --> F H["Capability滥用"] --> F I["Namespace配置错误"] --> B J["挂载宿主机目录"] --> B K["特权容器"] --> E end style F fill:#FF6B6B style G fill:#FF6B6B style K fill:#FF6B6B

1.4 当前态势：容器逃逸事件时间线#

graph TB subgraph "2019-2022: 内核漏洞驱动" A1["CVE-2019-5736<br/>runc宿主机文件写入"] A2["CVE-2022-0185<br/>cgroup整数溢出逃逸"] A3["CVE-2022-0492<br/>cgroup v1释放逃逸"] end subgraph "2023-2024: 运行时漏洞集中爆发" B1["CVE-2023-0461<br/>UAF导致容器逃逸"] B2["Leaky Vessels<br/>CVE-2024-21626/23951<br/>runc工作目录逃逸"] B3["CVE-2024-1086<br/>netfilter UAF提权"] end subgraph "2025-2026: K8s攻击面成为焦点" C1["RBAC过度授权滥用"] C2["Supply Chain: 恶意Helm Chart/Operator"] C3["eBPF滥用: 容器内内核级监控逃逸"] end

关键趋势：容器逃逸从”内核漏洞利用”演变为”多路径组合攻击”——攻击者不再依赖单一CVE，而是组合配置错误、权限滥用、供应链投毒等多种手法。

二、容器逃逸：六大路径#

2.1 路径一：内核漏洞逃逸#

最直接的逃逸方式——利用Linux内核漏洞突破Namespace隔离：

CVE类型逃逸机制影响范围
CVE-2024-21626runc工作目录泄露/proc/self/cwd指向宿主机FS所有使用runc的容器
CVE-2024-1086netfilter UAF内核double-free提权到root所有使用netfilter的内核
CVE-2022-0185cgroup整数溢出越界写导致Namespace逃逸cgroup v1内核
CVE-2019-5736runc文件写入通过/proc/self/exe覆盖runc二进制所有runc版本

以CVE-2024-21626为例，攻击流程：

graph LR A["攻击者控制容器内进程"] --> B["将WORKDIR设为/proc/self/cwd"] B --> C["runc在宿主机FS上操作"] C --> D["通过符号链接访问宿主机文件"] D --> E["写入SSH公钥或cron任务"] E --> F["获得宿主机root权限"]

防御：及时更新runc/containerd版本；使用Seccomp限制chdir相关系统调用；启用User Namespace将容器内root映射为宿主机非特权用户。

2.2 路径二：特权容器逃逸#

--privileged标志是容器安全的最大敌人：

# 特权容器——几乎等于宿主机root
privileged_container:
  capabilities: "ALL"           # 拥有所有Linux Capability
  seccomp: "unconfined"         # 无系统调用过滤
  devices: "访问所有设备"        # 可以读写/dev下所有设备
  namespaces: "可操作所有Namespace" # 可以进入其他进程的Namespace
  apparmor: "unconfined"        # 无AppArmor约束

特权容器中的逃逸手法极其简单：

# 方法1: 挂载宿主机磁盘
mount /dev/sda1 /mnt
echo " attacker-key" >> /mnt/root/.ssh/authorized_keys


# 方法2: 通过cgroup release_agent
mkdir /tmp/cgrp
mount -t cgroup -o rdma cgroup /tmp/cgrp
mkdir /tmp/cgrp/xx
echo 1 > /tmp/cgrp/xx/notify_on_release
echo "/tmp/cmd" > /tmp/cgrp/release_agent
# 宿主机以root执行release_agent


# 方法3: 加载内核模块
insmod malicious.ko  # 直接在宿主机内核中执行代码

防御：永远不要使用--privileged；按需授予最小Capability集合；使用Pod Security Standards的Restricted策略。

2.3 路径三：危险挂载逃逸#

将宿主机敏感目录挂载到容器中是常见的配置错误：

挂载路径风险逃逸方式
/宿主机完整文件系统直接读写任意文件
/proc内核进程信息读写/proc/*/mem修改进程内存
/sys内核参数修改内核配置、加载模块
/dev设备文件读写块设备、挂载磁盘
/var/run/docker.sockDocker守护进程创建特权容器、访问所有容器
/etc/kubernetesK8s配置读取管理员凭据、修改配置
/run/containerdcontainerd套接字通过containerd控制所有容器

docker.sock挂载是最常见的危险配置——很多CI/CD流水线为了在容器内构建Docker镜像，将宿主机的docker.sock挂载进容器。攻击者一旦进入容器，就可以：

# 在容器内通过docker.sock创建特权容器
docker run -v /:/host --privileged alpine
# 然后在新容器中读写宿主机文件系统

防御：禁止挂载宿主机敏感目录；使用Docker-in-Docker（DinD）替代docker.sock挂载；使用Kaniko/Buildah等无需Docker守护进程的构建工具。

2.4 路径四：Capability滥用#

Linux Capability将root权限拆分为细粒度能力。容器默认只保留部分Capability，但攻击者可以利用已授予的Capability提权：

# 容器默认Capability（Docker）
default_capabilities:
  - AUDIT_WRITE      # 写审计日志
  - CHOWN            # 修改文件所有者
  - DAC_OVERRIDE     # 绕过文件权限检查
  - FOWNER           # 绕过文件属主检查
  - FSETID           # 设置SUID位
  - KILL             # 发送信号
  - MKNOD            # 创建设备文件
  - NET_BIND_SERVICE # 绑定1024以下端口
  - NET_RAW          # 使用原始套接字
  - SETFCAP          # 设置文件Capability
  - SETGID           # 修改组ID
  - SETUID           # 修改用户ID
  - SETPCAP          # 修改进程Capability
  - SYS_CHROOT       # chroot


# 危险Capability（不应在容器中授予）
dangerous_capabilities:
  - SYS_ADMIN: "mount, pivot_root, namespace操作——几乎等于root"
  - SYS_PTRACE: "读写其他进程内存——可注入宿主机进程"
  - SYS_MODULE: "加载内核模块——直接在内核执行代码"
  - DAC_READ_SEARCH: "绕过目录权限——读取任意文件"
  - NET_ADMIN: "修改网络配置——ARP欺骗、路由劫持"

SYS_ADMIN是最危险的Capability——它允许mount、pivot_root、unshare等操作，足以完成容器逃逸。

防御：使用--cap-drop=ALL --cap-add=<仅需要的>最小化Capability；禁止SYS_ADMIN、SYS_PTRACE、SYS_MODULE。

2.5 路径五：应用程序漏洞逃逸#

容器内的应用漏洞可能被利用来执行任意代码，然后结合上述路径完成逃逸：

graph LR A["Web应用RCE漏洞"] --> B["获得容器内代码执行"] B --> C["探测容器环境"] C --> D["发现特权容器/docker.sock/危险Capability"] D --> E["利用配置缺陷逃逸到宿主机"] E --> F["横向移动到其他Pod/Node"]

这是最常见的攻击路径——应用漏洞是入口，配置缺陷是放大器。

2.6 路径六：供应链投毒#

恶意容器镜像或Helm Chart是容器供应链的威胁：

供应链攻击面攻击方式案例
恶意基础镜像Docker Hub上发布含后门的镜像2025年Docker Hub恶意镜像事件
依赖投毒在镜像构建过程中植入恶意包npm/pip供应链投毒
Helm Chart投毒恶意Chart部署特权Pod模仿热门Chart
Operator投毒恶意Operator获取集群级权限伪造CNCF项目
构建管道投毒CI/CD管道注入恶意层上一篇分析的Cache投毒

三、Kubernetes攻击面#

3.1 K8s攻击矩阵#

基于MITRE ATT&CK容器矩阵，K8s的主要攻击技术：

graph TB subgraph "初始访问" A1["暴露的API Server"] A2["暴露的kubelet"] A3["恶意镜像"] A4["应用漏洞"] end subgraph "执行" B1["kubectl exec"] B2["恶意Pod部署"] B3["命令注入"] end subgraph "持久化" C1["RBAC后门"] C2["CronJob"] C3["Mutating Webhook"] C4["etcd直接写入"] end subgraph "权限提升" D1["特权Pod"] D2["ServiceAccount Token"] D3["Node/Pod绑定"] end subgraph "横向移动" E1["Pod间网络扫描"] E2["ServiceAccount复用"] E3["云元数据访问"] end A1 --> B1 A4 --> B3 B1 --> C1 B2 --> D1 D1 --> E1 E3 --> F["云资源接管"]

3.2 API Server安全#

API Server是K8s的控制平面入口，也是攻击者的首要目标：

api_server_security:
  # 认证
  authentication:
    - "禁止匿名访问: --anonymous-auth=false"
    - "使用OIDC集成企业身份"
    - "禁用客户端证书以外的认证方式（按需）"


  # 授权（RBAC）
  authorization:
    - "始终使用RBAC: --authorization-mode=RBAC"
    - "禁止ABAC: 不使用--authorization-mode=ABAC"
    - "最小权限原则: 避免cluster-admin过度授权"


  # 准入控制
  admission_control:
    - "启用NodeRestriction: 限制kubelet仅操作自身Node的Pod"
    - "启用PodSecurity: 强制Pod Security Standards"
    - "启用ResourceQuota: 限制资源使用"
    - "部署OPA/Gatekeeper: 自定义准入策略"


  # 网络暴露
  network:
    - "API Server不应暴露在公网"
    - "使用VPN或跳板机访问"
    - "启用审计日志: --audit-log-path"

3.3 RBAC：权限管理的双刃剑#

RBAC是K8s权限管理的核心，也是最常见的配置错误来源：

# 危险RBAC配置示例
dangerous_rbac:
  # 反模式1: 过度授权cluster-admin
  - subject: "所有开发者"
    role: "cluster-admin"
    risk: "等同于集群root权限"


  # 反模式2: 通配符权限
  - apiGroups: ["*"]
    resources: ["*"]
    verbs: ["*"]
    risk: "对所有资源的所有操作权限"


  # 反模式3: Secret读取权限
  - apiGroups: [""]
    resources: ["secrets"]
    verbs: ["get", "list"]
    risk: "可读取所有Secret（含数据库密码、API密钥）"


  # 反模式4: Pod执行权限
  - apiGroups: [""]
    resources: ["pods", "pods/exec"]
    verbs: ["create", "get"]
    risk: "可在任何Pod中执行命令"


  # 反模式5: Pod创建+特权
  - apiGroups: [""]
    resources: ["pods"]
    verbs: ["create"]
    risk: "可创建特权Pod逃逸到宿主机"

RBAC权限提升的经典路径：

graph LR A["低权限ServiceAccount"] -->|"创建Pod"| B["特权Pod"] B -->|"容器逃逸"| C["宿主机root"] C -->|"读取/etc/kubernetes"| D["集群管理员凭据"] D -->|"完全控制集群"| E["Cluster Admin"] A -->|"读取Secret"| F["数据库密码/API密钥"] F -->|"横向移动"| G["其他系统/云资源"] A -->|"Pod exec"| H["进入其他Pod"] H -->|"窃取ServiceAccount Token"| I["更高权限的ServiceAccount"]

3.4 Pod安全：从SecurityContext到Pod Security Standards#

K8s的Pod安全经历了从PodSecurityPolicy（PSP，已废弃）到Pod Security Standards（PSS）的演进：

# Pod Security Standards三个级别
pod_security_standards:
  # Privileged: 不限制——危险
  privileged:
    - "允许特权容器"
    - "允许所有Capability"
    - "允许挂载宿主机路径"
    - "仅用于系统组件"


  # Baseline: 禁止明显危险的配置
  baseline:
    - "禁止特权容器"
    - "禁止危险Capability（SYS_ADMIN等）"
    - "禁止hostPath挂载"
    - "禁止hostNetwork/hostPID/hostIPC"
    - "禁止修改Seccomp配置"


  # Restricted: 严格限制——推荐
  restricted:
    - "必须以非root运行"
    - "必须丢弃所有Capability"
    - "必须启用SeccompProfile"
    - "必须设置readOnlyRootFilesystem"
    - "必须设置runAsNonRoot"
# Restricted Pod安全配置示例
apiVersion: v1
kind: Pod
metadata:
  name: secure-pod
spec:
  securityContext:
    runAsNonRoot: true
    runAsUser: 1000
    fsGroup: 2000
    seccompProfile:
      type: RuntimeDefault
  containers:
    - name: app
      image: app:latest
      securityContext:
        allowPrivilegeEscalation: false
        readOnlyRootFilesystem: true
        capabilities:
          drop: ["ALL"]
      volumeMounts:
        - name: tmp
          mountPath: /tmp
  volumes:
    - name: tmp
      emptyDir: {}

3.5 网络策略：微隔离的实现#

默认情况下，K8s中所有Pod可以互相通信——这在生产环境中是不可接受的：

# 默认拒绝所有入站流量
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-ingress
  namespace: production
spec:
  podSelector: {}  # 匹配所有Pod
  policyTypes:
    - Ingress


---
# 仅允许特定服务的流量
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend-to-api
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: api-server
  policyTypes:
    - Ingress
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app: frontend
      ports:
        - port: 8080

3.6 Secret管理#

K8s原生Secret是Base64编码（不是加密），etcd中明文存储：

# K8s Secret的安全问题
secret_risks:
  默认行为:
    - "Base64编码 ≠ 加密"
    - "etcd中明文存储"
    - "任何有读取权限的人可解码"
    - "节点上的Secret写入tmpfs（但可被同一节点Pod读取）"


  加固措施:
    - "启用etcd加密: --encryption-provider-config"
    - "使用外部密钥管理: HashiCorp Vault / AWS Secrets Manager"
    - "使用CSI Secrets Driver: 从外部KMS注入Secret"
    - "限制RBAC: 仅授权必要的Secret读取权限"
    - "审计Secret访问: 启用API审计日志"

四、容器运行时安全#

4.1 运行时威胁检测#

容器运行时安全工具监控容器行为，检测异常活动：

runtime_security:
  # 检测能力
  detection_capabilities:
    进程异常:
      - "容器内启动非预期进程（如反向Shell）"
      - "特权提升操作（如sudo、su）"
      - "异常的子进程（如Web服务器启动bash）"


    文件异常:
      - "写入非预期路径（如/etc、/usr/bin）"
      - "修改二进制文件"
      - "创建SUID文件"


    网络异常:
      - "非预期的出站连接"
      - "连接到元数据服务（169.254.169.254）"
      - "DNS隧道行为"
      - "端口扫描"


    系统调用异常:
      - "execve调用非预期二进制"
      - "mount/umount操作"
      - "keyctl操作（读取内核密钥环）"
      - "bpf系统调用（加载eBPF程序）"


  # 主流工具
  tools:
    - name: Falco
      type: "内核模块/eBPF"
      features: ["规则引擎", "SIEM集成", "K8s Audit Log"]


    - name: Tetragon
      type: "eBPF"
      features: ["内核级过滤", "低开销", "实时追踪"]


    - name: Tracee
      type: "eBPF"
      features: ["系统调用追踪", "容器感知", "签名检测"]

4.2 eBPF：安全监控的新范式#

eBPF（Extended Berkeley Packet Filter）正在改变容器运行时安全的格局——它可以在内核态运行沙箱程序，无需修改内核源码：

graph TB subgraph "传统方式" A1["内核模块"] --> B1["高权限<br/>可能崩溃内核"] A1 --> C1["性能开销大"] end subgraph "eBPF方式" A2["eBPF程序"] --> B2["沙箱执行<br/>验证器保证安全"] A2 --> C2["极低性能开销"] A2 --> D2["动态加载<br/>无需重启"] end style B1 fill:#FF6B6B style B2 fill:#90EE90

但eBPF也是双刃剑——攻击者也可以利用eBPF进行内核级监控和攻击：

ebpf_dual_use:
  # 防御者使用
  defender:
    - "Falco/Tetragon: 运行时安全监控"
    - "Cilium: 网络策略执行"
    - "进程追踪: 检测异常系统调用"


  # 攻击者使用
  attacker:
    - "内核级Rootkit: 隐藏进程和文件"
    - "网络嗅探: 捕获容器间流量"
    - "凭据窃取: 追踪read/write系统调用"
    - "绕过Seccomp: eBPF不受Seccomp限制"

五、纵深防御体系#

5.1 容器安全全生命周期#

graph LR subgraph "构建时" A1["基础镜像扫描"] A2["依赖漏洞检测"] A3["镜像签名"] end subgraph "部署时" B1["准入控制"] B2["Pod Security Standards"] B3["RBAC最小权限"] end subgraph "运行时" C1["运行时监控"] C2["网络策略"] C3["Secret加密"] end subgraph "响应时" D1["Pod隔离"] D2["取证快照"] D3["凭据轮换"] end A1 --> B1 B1 --> C1 C1 --> D1

5.2 构建时安全#

build_time_security:
  # 镜像安全
  image_security:
    - "使用最小基础镜像: distroless / alpine"
    - "固定镜像版本: 使用SHA256而非tag"
    - "镜像扫描: Trivy / Grype / Snyk Container"
    - "镜像签名: cosign / Docker Content Trust"
    - "多阶段构建: 构建依赖不出现在最终镜像"


  # 供应链安全
  supply_chain:
    - "SBOM生成: Syft / spdx"
    - "SLSA合规: 构建完整性验证"
    - "私有Registry: 避免直接从Docker Hub拉取"
    - "镜像拉取策略: Always + digest验证"

5.3 部署时安全#

deploy_time_security:
  # 准入控制
  admission_control:
    - "Pod Security Standards: enforce=restricted"
    - "OPA/Gatekeeper: 自定义策略（禁止hostPath等）"
    - "Kyverno: 策略引擎（自动修复配置）"
    - "镜像验证: 仅允许签名镜像"


  # RBAC
  rbac:
    - "最小权限: 按需授权，禁止通配符"
    - "命名空间隔离: 不同环境不同权限"
    - "定期审计: 检查过度授权的RoleBinding"
    - "ServiceAccount: 每个Pod独立SA，禁用默认SA的automountServiceAccountToken"


  # 网络策略
  network_policy:
    - "默认拒绝: 所有命名空间default-deny"
    - "白名单: 仅允许必要的Pod间通信"
    - "出口控制: 限制Pod的出站流量"
    - "DNS策略: 限制DNS查询范围"

5.4 运行时安全#

runtime_security_defense:
  # 容器运行时
  container_runtime:
    - "gVisor: 用户态内核，强隔离"
    - "Kata Containers: 轻量VM，硬件级隔离"
    - "Seccomp: 自定义系统调用过滤"
    - "AppArmor: 强制访问控制"


  # 监控
  monitoring:
    - "Falco: 运行时异常检测"
    - "Tetragon: eBPF内核级监控"
    - "K8s Audit Log: API调用审计"
    - "Prometheus + Alertmanager: 指标异常告警"


  # Secret管理
  secret_management:
    - "etcd加密: EncryptionConfiguration"
    - "外部KMS: Vault / AWS Secrets Manager"
    - "CSI Driver: 按需注入Secret"
    - "Secret轮换: 自动化定期轮换"

5.5 防御层对照表#

防御层针对威胁实现方式
镜像扫描恶意镜像/已知漏洞Trivy/Grype CI集成
镜像签名供应链投毒cosign + admission验证
Pod Security Standards特权容器/危险挂载PSS enforce=restricted
RBAC最小权限权限提升/横向移动按需授权 + 定期审计
NetworkPolicyPod间横向移动默认拒绝 + 白名单
运行时监控容器逃逸/异常行为Falco/Tetragon
gVisor/Kata内核漏洞逃逸强隔离运行时
Secret加密凭据窃取etcd加密 + 外部KMS
审计日志权限滥用/攻击溯源API Audit + SIEM

六、我的思考#

6.1 共享内核是容器安全的根本矛盾#

容器的优势——轻量、快速启动、高密度部署——全部来自共享内核。但共享内核意味着容器的隔离边界本质上是”软隔离”——不是硬件级的墙，而是内核代码实现的规则。只要内核有bug，规则就可能被绕过。

gVisor和Kata Containers试图解决这个矛盾——gVisor用用户态内核替代共享内核，Kata用轻量VM实现硬件隔离。但两者都有性能和兼容性代价。在2026年，大多数生产环境仍然使用runc + 共享内核，这意味着容器逃逸风险将持续存在。

6.2 K8s的”默认不安全”需要改变#

K8s的默认配置是”功能优先”——所有Pod可以互相通信、默认ServiceAccount自动挂载Token、RBAC策略宽松。这在开发阶段方便，但在生产环境中是灾难。

Pod Security Standards从PSP演进而来，但enforce=restricted仍然不是默认值。K8s社区需要在安全与易用之间做出选择——而历史表明，“默认安全”是唯一可持续的选择。

6.3 容器逃逸不是终点，而是起点#

容器逃逸获得宿主机权限后，攻击者的下一步通常是：

  1. 读取/etc/kubernetes下的管理员凭据
  2. 通过IMDS（169.254.169.254）获取云平台临时凭证
  3. 使用云凭证接管整个云环境

这意味着容器安全不是孤立的——它是云安全链条中的一环。上一篇分析的供应链投毒可以植入恶意镜像，本篇分析的容器逃逸可以从恶意镜像到达宿主机，下一篇将分析的云IAM滥用可以从宿主机到达云资源。攻防是一个连续的链条。

6.4 eBPF是容器安全的未来，也是新的攻击面#

eBPF正在成为容器运行时安全的基础设施——Falco、Tetragon、Cilium都依赖eBPF。但eBPF的CAP_BPF/CAP_SYS_ADMIN权限要求意味着只有特权进程才能加载eBPF程序。攻击者一旦获得这些权限，也可以利用eBPF实现内核级Rootkit——这种Rootkit比传统内核模块更难检测，因为eBPF程序经过验证器验证，被认为是”安全的”。

七、总结#

容器与Kubernetes安全的核心挑战是：共享内核的隔离模型本质上比虚拟机弱，而K8s的默认配置倾向于易用而非安全。攻击者从应用漏洞进入容器，利用配置缺陷逃逸到宿主机，再通过云元数据到达云资源——这是一条完整的攻击链。

2026年的容器安全需要四个转变：

  1. 从默认开放到默认拒绝——Pod Security Standards enforce=restricted、NetworkPolicy默认拒绝、RBAC最小权限
  2. 从静态扫描到运行时监控——镜像扫描只解决已知漏洞，运行时监控才能发现未知攻击
  3. 从软隔离到强隔离——对高价值工作负载使用gVisor/Kata Containers，不依赖共享内核
  4. 从单点防御到链条防御——容器安全不是孤立的，需要与供应链安全、云IAM、事件响应联动

下一篇将分析云身份与权限管理——当攻击者从容器逃逸到宿主机，云IAM如何成为他们下一个目标，以及如何成为防御者的第一道防线。

参考来源：CVE-2024-21626 (runc working directory leak), MITRE ATT&CK Container Matrix, Kubernetes Pod Security Standards, Falco/Tetragon运行时安全文档.

参考#

支持与分享

如果这篇文章对你有帮助，欢迎支持作者或分享给更多人

赞助
容器与Kubernetes安全：从共享内核到容器逃逸的攻防全景
https://blog.souloss.com/posts/cloud-security/container-kubernetes-security-attack-defense/
作者
Souloss
发布于
2025-02-21
许可协议
CC BY-NC-SA 4.0

部分信息可能已经过时

DeepSeek R1 与 GRPO：开源推理模型的突破
T5/FLAN：Encoder-Decoder与指令微调
相关文章 智能推荐
1
云身份与权限管理：IAM如何成为云安全的第一战场
云安全攻防技术 云IAM是攻击者的第一目标和防御者的第一防线——从AWS IAM特权提升到GCP Service Account滥用，解析云身份的信任模型、攻击路径与纵深防御。
2
供应链投毒与CI/CD安全：从TanStack事件看云安全信任链
云安全攻防技术 TanStack npm供应链投毒事件深度复盘——pull_request_target + Cache投毒 + OIDC内存提取三链攻击，解析CI/CD管道信任边界问题与防御体系。
3
云安全态势管理：配置错误为何是云安全的第一大威胁
云安全攻防技术 超过70%的云安全事件源于配置错误——从公开S3桶到过度宽松的安全组，解析云配置偏差的根因、CSPM的检测逻辑与自动修复体系。
4
云安全系列导读
云安全攻防技术 云安全系列导读——从威胁模型到防护体系的完整学习路径
5
AI武器化与云安全新战场：当攻击者开始武装AI
云安全攻防技术 AI如何改变云安全攻防格局——伪造AI身份、AI加速攻击链设计、训练数据投毒与CI/CD投毒的攻击哲学共性，以及AI辅助防御的新方向。
随机文章 随机推荐
1
TLS 1.3 握手详解
密码学与安全工程 2026-03-23
2
DPDK 多核与并发模型
高性能网络 2025-05-17
3
用户工具：ls、cat、cp 等命令
操作系统 2021-11-15
4
同态加密
密码学与安全工程 2026-04-20
5
性能计数器与 Top-Down 分析
CPU与计算机体系结构 2026-03-19
© 2026 Souloss. All Rights Reserved. / RSS / Atom / Sitemap
Powered by Astro & souloss  Version 9.0