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

TL;DR

• 场景:2026-07-13 当周 Hugging Face 平台披露,攻击者通过上传恶意 Dataset 触发 Remote-code dataset loader + Template injection 两条代码执行路径,在数据处理 Worker 上取得执行权限,然后提权到节点并横向移动到多个内部集群,收割云与集群凭据。
• 结论:Dataset 处理的真正风险不是文件本身,而是"读取动作被升级为任意代码执行"——Loader、模板、依赖、网络与身份任一环节失控,都可能把普通数据处理变成横向移动的起点。控制目标不是堵住所有漏洞,而是让任意代码执行无法升级为节点、凭据和集群入侵。
• 产出:覆盖资产/信任边界、8 大威胁枚举、Canonical Manifest、Admission Control 七条规则、一次性 Worker 基线、默认拒绝网络、短期身份、运行时证据、6 次攻击验证和典型失败模式,作为可落地的 Dataset Processing Threat Model 蓝本。

版本矩阵

发布边界：本文给出的是供应链威胁模型与示意配置，不是适用于所有集群的可直接部署清单；gVisor、Kata、NetworkPolicy 与工作负载身份必须按实际平台兼容性验证。

发布边界：本文给出的是供应链威胁模型与示意配置，不是适用于所有集群的可直接部署清单；gVisor、Kata、NetworkPolicy 与工作负载身份必须按实际平台兼容性验证。

核心结论：安全设计必须假设 Dataset、Loader、模板和依赖中至少有一项会执行任意代码。控制目标不是阻止所有漏洞，而是让任意代码执行无法升级为节点、凭据和集群入侵。

资产与信任边界

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

信任边界至少有五层：上传入口；Manifest 与策略层；执行 Worker；Node/Runtime；内部服务与云控制面。只在上传入口做扫描，会漏掉运行时产生的下载、动态依赖、模板展开和第二阶段 Payload。

威胁枚举

Canonical Manifest

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

apiVersion:processing.ascendlab.dev/v1kind:DatasetJobManifestmetadata:tenant:tenant_123job_id:job_20260718_001spec:dataset:source:hf://org/name@revisioncontent_digest:sha256:...loader:mode:declarative-onlyartifact_digest:sha256:...remote_code:falsedependencies:lock_digest:sha256:...network_install:falseexecution:image_digest:registry/app@sha256:...timeout_seconds:300cpu:"2"memory:4Ginetwork:policy:deny-by-defaultallow:-host:object-store.internalport:443identity:audience:dataset-processorttl_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/v1kind:Jobmetadata:name:dataset-job-20260718-001namespace:untrusted-processingspec:ttlSecondsAfterFinished:300template:spec:automountServiceAccountToken:falserestartPolicy:NeverruntimeClassName:gvisorsecurityContext:runAsNonRoot:trueseccompProfile:type:RuntimeDefaultcontainers:-name:workerimage:registry/processor@sha256:...securityContext:allowPrivilegeEscalation:falsereadOnlyRootFilesystem:truecapabilities:drop:["ALL"]resources:limits:cpu:"2"memory:4Giephemeral-storage:8GivolumeMounts:-name:scratchmountPath:/workvolumes:-name:scratchemptyDir:sizeLimit:8Gi

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

默认拒绝网络

apiVersion:networking.k8s.io/v1kind:NetworkPolicymetadata:name:deny-allnamespace:untrusted-processingspec: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 之外写入不可变存储，防止攻击者清理现场。

验证方法

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

错误速查卡