从恶意数据集到横向移动：数据集处理威胁模型与五层控制

从恶意 Dataset 到横向移动:一套可落地的 Dataset Processing Threat Model

先说几个核心判断。

2026年7月13日那周，Hugging Face 平台遭遇了一次典型的 AI Agent 自主攻击。攻击者通过上传恶意 Dataset，触发了 Remote-code dataset loader 和 Template injection 两条代码执行路径，在数据处理 Worker 上拿到了执行权限。然后——这还没完——他们成功提权到节点，横向移动到多个内部集群，顺手收割了云与集群凭据。

这件事揭示了一个关键问题：Dataset 处理的真正风险，从来不是文件本身有什么问题，而是“读取动作被升级为任意代码执行”。Loader、模板、依赖、网络与身份，任何一个环节失控，都可能把一次普通的数据处理变成横向移动的起点。所以控制目标不是堵住所有漏洞——这不现实——而是确保任意代码执行无法升级为节点入侵、凭据窃取和集群沦陷。

这篇文章会产出什么？一套完整的 Dataset Processing Threat Model 蓝本，覆盖资产与信任边界、8 大威胁枚举、Canonical Manifest、Admission Control 七条规则、一次性 Worker 基线、默认拒绝网络、短期身份、运行时证据、6 次攻击验证和典型失败模式。全是可落地的内容。

版本矩阵

资产与信任边界

需要保护的资产包括哪些？租户数据、内部 Dataset、云与集群身份、对象存储、模型与镜像 Registry、处理结果完整性、审计日志和平台可用性，一个都不能少。

信任边界至少要有五层：上传入口是第一道；Manifest 与策略层是第二道；执行 Worker 是第三道；Node/Runtime 是第四道；内部服务与云控制面是第五道。只在上传入口做扫描，那会漏掉运行时产生的下载、动态依赖、模板展开和第二阶段 Payload——相当于只修了大门，窗户全开着。

威胁枚举

Canonical Manifest

所有待处理资产，必须先归一化为一个可签名的 Manifest。名称不是信任依据，Digest 和解析后的实际执行计划才是。

apiVersion: processing.ascendlab.dev/v1
kind: DatasetJobManifest
metadata:
  tenant: tenant_123
  job_id: job_20260718_001
spec:
  dataset:
    source: hf://org/name@revision
    content_digest: sha256:...
  loader:
    mode: declarative-only
    artifact_digest: sha256:...
    remote_code: false
  dependencies:
    lock_digest: sha256:...
    network_install: false
  execution:
    image_digest: registry/app@sha256:...
    timeout_seconds: 300
    cpu: "2"
    memory: 4Gi
  network:
    policy: deny-by-default
    allow:
    - host: object-store.internal
      port: 443
  identity:
    audience: dataset-processor
    ttl_seconds: 600

Fingerprint 应该覆盖规范化后的 Dataset Revision、Loader、模板、依赖锁文件、容器镜像、命令、参数、网络策略和身份策略。任何关键项发生变化，都应该重新进入审批或隔离队列——不能悄无声息地放行。

Admission Control

Admission 不只是检查 Kubernetes 字段，还要检查业务级的 Manifest：

• 禁止 remote_code=true 进入普通 Worker Pool。
• 镜像必须使用 Digest，不允许可变 Tag。
• 禁止 privileged、hostNetwork、hostPID、hostIPC、hostPath 和容器运行时 Socket。
• 禁止自动挂载 ServiceAccount Token。
• 只允许经过签名的 Loader、镜像和依赖清单。
• 网络 Allowlist 必须非空且与任务类型匹配。
• 高风险任务进入 gVisor/Kata/VM 级隔离池，而不是普通容器池。

一次性 Worker 基线

下面是示意配置，注意——不是可以直接复制到所有集群的完整生产清单，需要根据实际情况调整：

apiVersion: batch/v1
kind: Job
metadata:
  name: dataset-job-20260718-001
  namespace: untrusted-processing
spec:
  ttlSecondsAfterFinished: 300
  template:
    spec:
      automountServiceAccountToken: false
      restartPolicy: Never
      runtimeClassName: gvisor
      securityContext:
        runAsNonRoot: true
        seccompProfile:
          type: RuntimeDefault
      containers:
      - name: worker
        image: registry/processor@sha256:...
        securityContext:
          allowPrivilegeEscalation: false
          readOnlyRootFilesystem: true
          capabilities:
            drop: ["ALL"]
        resources:
          limits:
            cpu: "2"
            memory: 4Gi
            ephemeral-storage: 8Gi
        volumeMounts:
        - name: scratch
          mountPath: /work
      volumes:
      - name: scratch
        emptyDir:
          sizeLimit: 8Gi

Restricted Pod Security、Seccomp/AppArmor/SELinux 和专用沙箱运行时解决不同层次的问题，不能互相替代。[1][4][5]

默认拒绝网络

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all
  namespace: untrusted-processing
spec:
  podSelector: {}
  policyTypes: [Ingress, Egress]

随后按 FQDN Gateway、固定袋里或受控对象存储端点放行。原生 NetworkPolicy 主要基于 IP/Port；域名级控制通常需要 Egress Proxy、Service Mesh 或云防火墙来补充。[2]

必须显式阻断的包括：云 Metadata Endpoint、Kubernetes API Server（除非有严格袋里）、容器 Registry 管理接口、CI/CD、Secret Manager 管理面和非任务相关的内部网段。

短期身份

身份应该满足几个条件：任务绑定、受众限制、十分钟级 TTL、最小 Scope、不可横向复用、任务结束自动撤销。Worker 不应该持有可以创建新身份、读取其他租户对象或修改控制面的权限。Kubernetes Secret 需要加密、最小 RBAC 和审计，但更优的方案是按任务签发短期身份，而不是挂载长期 Secret。[3]

运行时证据

每个任务至少保留：Manifest Digest、镜像 Digest、Node、Runtime Class、进程树、网络连接、文件写入摘要、身份签发与使用、策略判定、输出 Digest 和销毁时间。日志需要在 Worker 与 Node 之外写入不可变存储，防止攻击者清理现场——这是关键，如果日志只写在 Pod 里，Pod 一删就什么都没了。

验证方法

1. 在无真实凭据的测试集群执行恶意 Loader，确认无法访问 Metadata、API Server、邻接 Pod 和宿主路径。
2. 注入 DNS 隧道、反向连接和大流量下载，验证 Egress 阻断与告警。
3. 尝试读取默认 ServiceAccount Token、环境变量和挂载 Secret。
4. 用可变 Tag 替换镜像，确认 Admission 拒绝。
5. 修改 Loader 或配置模板，确认 Fingerprint 变化触发重新审批。
6. 删除 Pod，确认进程与网络证据仍在外部日志系统可检索。

失败模式

• 只做病毒扫描，不做执行计划和依赖审计。
• 允许 Worker 直接访问公网包仓库。
• 所有任务共享同一个 Node Pool、缓存和 ServiceAccount。
• 用 NetworkPolicy 替代沙箱运行时，或用沙箱运行时替代身份最小化。
• 签名通过后就假设内容安全。签名只证明来源和完整性，不证明没有恶意逻辑。[6]

参考资料

1. Kubernetes Pod Security Standards
2. Kubernetes Network Policies
3. Kubernetes Service Accounts 与短期 Token
4. gVisor Kubernetes Quick Start
5. Kubernetes Linux Kernel Security Constraints
6. Kubernetes Secrets Good Practices

错误速查卡