专栏：《AI 工程与安全深度实战》· 第3轮·第3篇（融合篇）目录前言1. 技术背景与演进逻辑1.1 从边界安全到零信任：AI 时代的范式迁移1.2 AI 基础设施的独特安全挑战1.3 安全左移：平台工程的必然选择2. 核心原理深度解析2.1 零信任 AI 基础设施的三大支柱2.2 平台工程中的安全左移机制2.3 大规模推理集群的安全监控架构2.4 AI 工作负载异常检测引擎设计3. 核心模块/流程/机制详解3.1 零信任策略引擎：从 OPA/Gatekeeper 到策略即代码3.2 安全左移流水线：全链路安全门禁3.3 推理集群异常检测系统：从 Falco 到 AI 驱动的行为分析4. 技术优缺点与适用场景5. 实战落地5.1 OPA/Gatekeeper 策略即代码实战5.2 Falco + 自定义规则检测推理异常5.3 生产避坑经验6. 全文总结免责声明本期专栏更新说明专栏推荐参考资料前言核心痛点：当企业的 AI 推理集群从单集群几台 GPU 节点扩张到多集群数千张加速卡时，传统的"边界防火墙 + 内网全信任"安全模型彻底失效。平台团队面临着三重困境——算力资产暴露面急剧扩大、模型权重和推理数据成为高价值攻击目标、安全策略与业务迭代速度严重脱节。本文系统性地解决这三个问题，提出以零信任架构为骨架、以安全左移为方法论、以异常检测为感知神经的 AI 基础设施安全体系。适配人群：具备 Kubernetes 和 AI 推理基础的中高阶平台工程师、安全架构师、DevSecOps 从业者，希望将安全能力系统性嵌入 AI 基础设施的团队技术负责人。收获能力：读完本文，你将掌握：(1) 零信任架构在 AI 推理基础设施中的落地方法论——从身份、网络、工作负载三个维度构建"永不信任、始终验证"的防御体系；(2) 平台工程中的安全左移实战——将安全门禁嵌入 CI/CD 流水线、镜像构建、模型交付的每一个环节；(3) 大规模推理集群的异常检测系统设计——从系统调用级监控到 AI 驱动的行为基线分析；(4) 可直接复制到生产环境的 OPA 策略模板、Falco 规则和 Prometheus 告警配置。1. 技术背景与演进逻辑1.1 从边界安全到零信任：AI 时代的范式迁移传统企业安全模型依赖一个核心假设：内网是可信的，外网是不可信的。安全预算的大头花在边界防火墙上，而内网东西向流量几乎不受审查。这种"城堡+护城河"模型在 AI 基础设施场景下暴露出致命缺陷。AI 推理集群的攻击面与传统微服务有本质不同。一个典型的 vLLM 推理 Pod（v0.8.5，2026 年 6 月最新稳定版），其攻击面包括：攻击面层级具体风险点传统防护盲区模型权重层权重文件被宿主机 root 读取、Sidecar 容器越权访问边界防火墙不可见推理数据层用户 Prompt 在内存中明文驻留、PII 数据经 GPU 显存传输网络层加密无法覆盖GPU 资源层恶意容器占用 GPU 算力挖矿、越权访问 MIG 分区资源配额无法感知攻击意图调度控制层伪造 GPU 资源请求、劫持调度器扩展点（Scheduler Extender）API Server 审计日志覆盖不全模型服务层Prompt Injection 绕过应用防火墙、模型输出泄露训练数据WAF 规则不适用于 LLM 语义攻击NIST SP 800-207 定义了零信任的核心理念——“永不信任，始终验证”（Never Trust, Always Verify）。2026 年 3 月，Microsoft 正式发布了 Zero Trust for AI（ZT4AI）参考架构，将零信任三原则——显式验证（Verify Explicitly）、最小权限（Use Least Privilege）、假设已遭入侵（Assume Breach）——扩展到了 AI 全生命周期。几乎同期，NVIDIA 发布了 Confidential AI Factory 参考架构，将机密计算（Confidential Computing）与零信任结合，通过硬件 TEE（Trusted Execution Environment）将信任边界从 Host OS 下推到 CPU/GPU 硬件层面。AI 基础设施安全演进的三个关键节点：传统边界安全 零信任网络 零信任 AI 基础设施 (2010-2020) (2020-2025) (2025-) │ │ │ ├── 防火墙+VPN ├── 微分段+mTLS ├── 机密容器+GPU TEE ├── 内网全信任 ├── 身份即边界 ├── 模型即边界 ├── 静态规则 ├── 动态策略 ├── AI 驱动策略 └── 人工响应 └── 半自动 SOAR └── 自主检测+响应为什么 AI 时代必须走向零信任？三个核心驱动力：算力资产的不可替代性：一台 8×H200 的 GPU 节点采购成本超过 30 万美元，其上的模型权重可能价值数千万美元（训练成本）。攻击者入侵一个推理 Pod 即可窃取完整权重——这在传统安全模型中是完全可能的，因为 Pod 内的 sidecar 容器默认不受东西向流量审查。推理数据的多租户混部：生产环境中，不同租户的推理请求可能路由到同一 GPU 节点的不同 MIG 分区。传统的 VLAN 隔离无法阻止一个租户通过 GPU 侧信道（如功耗分析、显存时序）推断另一租户的推理内容。攻击面的动态变化：AI 推理服务每周可能有数十次模型更新、镜像重建、拓扑变更。人工维护安全策略的速度远远跟不上——唯一可行的方案是将安全策略嵌入平台层，使其随基础设施自动演进。1.2 AI 基础设施的独特安全挑战与传统 Web 应用相比，AI 推理基础设施在安全上面临五类独特挑战：挑战一：GPU 内存的明文暴露在传统容器运行时（如 Docker/containerd）中，GPU 显存内容对宿主机 root 用户完全可见。通过nvidia-smi可以列出所有进程的显存使用，通过 CUDA Debug API 甚至可以 dump 显存内容。在模型推理过程中，权重矩阵在显存中以明文存储——这意味着任何一个获得宿主机 root 权限的攻击者，都可以完整窃取模型权重。挑战二：模型服务的东西向流量一个典型的 AI 推理请求链路涉及多个微服务：[客户端] → [API Gateway/Envoy] → [推理网关] → [vLLM Runtime] → [GPU Device Plugin] → [GPU] ↓ [模型缓存层/Redis] ↓ [监控导出/Prometheus]在这个链路中，API Gateway 到推理网关、推理网关到 vLLM Runtime、vLLM Runtime 到模型缓存层——这四段东西向流量在传统部署中均未加密。攻击者只需要在集群内部获得一个立足点（例如通过一个存在漏洞的 Jupyter Notebook 容器），即可嗅探全部推理流量。挑战三：模型供应链的信任传递一个生产推理服务依赖的软件供应链包括：组件典型来源信任风险基础镜像Docker Hub / NVIDIA NGC镜像被投毒、包含恶意层CUDA/cuDNN 运行时NVIDIA 官方源中间人替换、版本回退攻击vLLM/TGI 推理引擎PyPI / GitHub Release依赖混淆、Release 签名伪造模型权重文件Hugging Face / 私有存储权重被替换（缺乏完整性校验）自定义推理代码内部 Git 仓库代码审查绕过、硬编码密钥挑战四：推理请求的语义层攻击模型推理服务面临的不仅是传统的网络层攻击（DDoS、端口扫描），还有针对 LLM 的语义层攻击：Prompt Injection：将恶意指令嵌入用户输入，绕过系统提示词的安全约束Jailbreak：通过精心构造的对话上下文，使模型突破安全对齐Data Extraction：通过特定查询模式，诱导模型泄露训练数据中的 PIIModel Denial of Service：构造计算复杂度极高的推理请求（如要求生成长度为 128K 的序列），耗尽 GPU 算力传统 WAF 的签名匹配规则对这类攻击完全无效——因为它们不依赖已知的攻击模式，而是利用模型行为的固有特性。挑战五：可观测性的安全盲区AI 推理集群的可观测性栈（Prometheus + Grafana + GPU Exporter）通常关注性能指标——延迟、吞吐、GPU 利用率、显存占用。但以下安全关键指标往往缺失：推理请求的 Prompt 长度异常分布（可能指示 DoS 攻击）模型输出熵值的异常变化（可能指示权重被篡改）GPU 内核函数的非预期调用模式（可能指示侧信道攻击）容器内文件系统的非预期写入（可能指示后门植入）1.3 安全左移：平台工程的必然选择安全左移（Shift Left Security）的核心理念是将安全控制从生产运维阶段前移到开发和构建阶段——越早发现安全问题，修复成本越低。平台工程（Platform Engineering）则为安全左移提供了理想的载体：通过内部开发者平台（IDP）将安全门禁嵌入开发者工作流的每一个环节。在 AI 基础设施场景下，安全左移的具体含义是：安全控制点前移路径： 传统（右移） 左移后 修复成本对比 ───────────────────────────────────────────────────────────────────── 生产环境发现漏洞 → CI 流水线中被阻断 1:100 （传统修复成本 100×） 代码审查发现配置错误 → IDE 插件实时提示 1:10 上线后安全扫描 → 镜像构建时即扫描 1:50 人工渗透测试 → 自动化安全回归测试 1:30 事件响应 → 灰度发布+自动回滚 1:20平台工程实现安全左移的五个关键嵌入点：[开发者工作站] [CI 流水线] [镜像仓库] [K8S 集群] [运行时] │ │ │ │ │ ├── IDE 安全插件 ├── SAST/依赖扫描 ├── 镜像签名 ├── 准入控制 ├── 运行时检测 ├── Pre-commit Hook ├── IaC 安全扫描 ├── SBOM 生成 ├── 网络策略 ├── 异常行为分析 ├── 敏感信息检测 ├── 容器镜像扫描 ├── 漏洞数据库关联 ├── 资源配额 ├── eBPF 系统调用 └── 策略即文档 └── 策略合规检查 └── 签名验证 └── 运行时策略 └── 自动隔离2. 核心原理深度解析2.1 零信任 AI 基础设施的三大支柱零信任 AI 基础设施并非单一技术，而是由三个相互关联的支柱构成的体系。我将这三者称为"零信任 AI 基础设施的三角架构"：零信任 AI 基础设施 │ ├── [支柱一：身份与访问] │ ├── SPIRE/SPIFFE (工作负载身份) │ ├── OPA/Gatekeeper (策略即代码) │ ├── Workload Identity │ ├── JWT Token Review │ └── 动态 RBAC │ ├── [支柱二：网络与通信] │ ├── mTLS + Istio │ ├── Cilium NetworkPolicy │ ├── 微分段 (Microsegmentation) │ ├── eBPF 流量审计 │ └── L7 推理协议深度检查 │ └── [支柱三：工作负载与数据] ├── 机密容器 (CoCo) ├── TEE 可信执行 ├── Remote Attestation ├── 模型加密存储 └── 内存加密支柱一：身份与访问控制传统 Kubernetes RBAC 基于 ServiceAccount Token，但 Token 本身缺乏工作负载的身份证明——任何获得 Token 的容器都可以冒充该 ServiceAccount。SPIFFE（Secure Production Identity Framework for Everyone）通过 SPIFFE Verifiable Identity Document (SVID) 提供了密码学上可验证的工作负载身份。SPIRE（SPIFFE Runtime Environment）v1.11.0（2026 年 6 月最新版）的架构：[SPIRE Server] [SPIRE Agent] (每个节点一个) │ │ ├── 签发 SVID (X.509/JWT) ├── 节点本地 Unix Socket ├── 管理信任域 (Trust Domain) ├── 工作负载注册 (Workload Registration) ├── 对接外部 CA (Vault/CertManager) ├── 密钥/证书轮换 └── 联邦信任 (Federation) └── 工作负载 AttestationAI 推理场景下的 SPIFFE ID 设计示例：工作负载类型SPIFFE ID 格式权限边界vLLM 推理服务spiffe://ai-platform.prod/ns/inference/sa/vllm-server仅可访问模型存储和缓存模型下载 Sidecarspiffe://ai-platform.prod/ns/inference/sa/model-fetcher仅可读取模型仓库监控 Exporterspiffe://ai-platform.prod/ns/monitoring/sa/gpu-exporter仅可读取 GPU 指标调度器spiffe://ai-platform.prod/ns/kube-system/sa/ai-scheduler可读写调度决策OPA/Gatekeeper 策略执行流程：[API Server 请求] ↓ [认证 (Authentication)] ↓ [授权 (Authorization) ── RBAC] ↓ [准入控制 (Admission)] │ ├── Mutating Webhook ──→ 注入 Sidecar / 修改资源请求 │ └── Validating Webhook ──→ Gatekeeper (OPA) │ ├── 策略 1：镜像必须来自受信仓库 ├── 策略 2：必须设置 GPU 资源限制 ├── 策略 3：禁止 Privileged 容器 ├── 策略 4：必须声明 MIG 分区 ├── 策略 5：必须挂载信任的 ServiceAccount └── 策略 6：禁止挂载 HostPath支柱二：网络与通信安全零信任网络的核心原则是"默认拒绝，显式允许"——所有网络通信都需要明确授权，不存在隐式信任。AI 推理集群的微分段策略设计：[推理网关 (Inference Gateway)] │ ├──→ [vLLM Server :8000] 允许 ← gRPC 推理请求 ├──→ [Model Cache :6379] 允许 ← Redis 模型缓存查询 ├──→ [Control Plane :6443] 拒绝 ← 无理由访问 API Server └──→ [External :443] 拒绝 ← 无理由出站 [vLLM Server :8000] │ ├──→ [Model Storage :9000] 允许 ← 拉取模型权重 ├──→ [Shared Memory :shm] 允许 ← NCCL 集合通信 ├──→ [GPU Device Plugin :kubelet] 允许 ← GPU 分配 ├──→ [Other vLLM Pods] 拒绝 ← 默认隔离 └──→ [Internet] 拒绝 ← 禁止出站Cilium（v1.17.0，2026 年稳定版）通过 eBPF 实现了内核级网络策略执行，性能开销极低。对于 AI 推理场景的一个关键能力是L7 协议感知——不仅控制 IP:Port 级别通信，还能检查 HTTP/gRPC 的具体 API 路径：# CiliumNetworkPolicy: 推理 API 的 L7 访问控制apiVersion:cilium.io/v2kind:CiliumNetworkPolicymetadata:name:inference-api-policynamespace:inferencespec:endpointSelector:matchLabels:app:vllm-serveringress:-fromEndpoints:-matchLabels:app:inference-gatewaytoPorts:-ports:-port:"8000"protocol:TCPrules:http:-method:POSTpath:"/v1/completions"# 仅允许推理 API-method:POSTpath:"/v1/chat/completions"# 拒绝 /v1/models (模型列表泄露风险)# 拒绝 /health (可被用于存活探测扫描)支柱三：工作负载与数据安全机密容器（Confidential Containers, CoCo）将零信任的边界从操作系统层面下推到硬件层面。基于 Kata Containers v3.14.0 和 NVIDIA Confidential Computing 技术栈，AI 推理工作负载可以运行在硬件加密的 TEE 中——即使宿主机 root 也无法读取模型权重和推理数据。机密容器的信任边界对比：传统容器 机密容器 (CoCo) ───────── ──────────────── Trusted: Host OS + Hypervisor Untrusted: Host OS + Hypervisor Untrusted: 容器进程（相对） Trusted: 仅 TEE 内部（CPU TEE + GPU TEE） 信任根： Host OS Kernel 信任根： Hardware (CPU + GPU) 认证方式：容器命名空间隔离 认证方式：Remote Attestation (硬件密码学证明) Secret 保护：K8S Secret (etcd 明文) Secret 保护：KBS (Key Broker Service) + 加密内存Remote Attestation 流程（基于 RATS 架构）：[AI 推理容器 (TEE 内)]
【高阶·融合】零信任 AI 基础设施架构深度解析：从安全左移到大规模推理集群异常检测
专栏：《AI 工程与安全深度实战》· 第3轮·第3篇（融合篇）目录前言1. 技术背景与演进逻辑1.1 从边界安全到零信任：AI 时代的范式迁移1.2 AI 基础设施的独特安全挑战1.3 安全左移：平台工程的必然选择2. 核心原理深度解析2.1 零信任 AI 基础设施的三大支柱2.2 平台工程中的安全左移机制2.3 大规模推理集群的安全监控架构2.4 AI 工作负载异常检测引擎设计3. 核心模块/流程/机制详解3.1 零信任策略引擎：从 OPA/Gatekeeper 到策略即代码3.2 安全左移流水线：全链路安全门禁3.3 推理集群异常检测系统：从 Falco 到 AI 驱动的行为分析4. 技术优缺点与适用场景5. 实战落地5.1 OPA/Gatekeeper 策略即代码实战5.2 Falco + 自定义规则检测推理异常5.3 生产避坑经验6. 全文总结免责声明本期专栏更新说明专栏推荐参考资料前言核心痛点：当企业的 AI 推理集群从单集群几台 GPU 节点扩张到多集群数千张加速卡时，传统的"边界防火墙 + 内网全信任"安全模型彻底失效。平台团队面临着三重困境——算力资产暴露面急剧扩大、模型权重和推理数据成为高价值攻击目标、安全策略与业务迭代速度严重脱节。本文系统性地解决这三个问题，提出以零信任架构为骨架、以安全左移为方法论、以异常检测为感知神经的 AI 基础设施安全体系。适配人群：具备 Kubernetes 和 AI 推理基础的中高阶平台工程师、安全架构师、DevSecOps 从业者，希望将安全能力系统性嵌入 AI 基础设施的团队技术负责人。收获能力：读完本文，你将掌握：(1) 零信任架构在 AI 推理基础设施中的落地方法论——从身份、网络、工作负载三个维度构建"永不信任、始终验证"的防御体系；(2) 平台工程中的安全左移实战——将安全门禁嵌入 CI/CD 流水线、镜像构建、模型交付的每一个环节；(3) 大规模推理集群的异常检测系统设计——从系统调用级监控到 AI 驱动的行为基线分析；(4) 可直接复制到生产环境的 OPA 策略模板、Falco 规则和 Prometheus 告警配置。1. 技术背景与演进逻辑1.1 从边界安全到零信任：AI 时代的范式迁移传统企业安全模型依赖一个核心假设：内网是可信的，外网是不可信的。安全预算的大头花在边界防火墙上，而内网东西向流量几乎不受审查。这种"城堡+护城河"模型在 AI 基础设施场景下暴露出致命缺陷。AI 推理集群的攻击面与传统微服务有本质不同。一个典型的 vLLM 推理 Pod（v0.8.5，2026 年 6 月最新稳定版），其攻击面包括：攻击面层级具体风险点传统防护盲区模型权重层权重文件被宿主机 root 读取、Sidecar 容器越权访问边界防火墙不可见推理数据层用户 Prompt 在内存中明文驻留、PII 数据经 GPU 显存传输网络层加密无法覆盖GPU 资源层恶意容器占用 GPU 算力挖矿、越权访问 MIG 分区资源配额无法感知攻击意图调度控制层伪造 GPU 资源请求、劫持调度器扩展点（Scheduler Extender）API Server 审计日志覆盖不全模型服务层Prompt Injection 绕过应用防火墙、模型输出泄露训练数据WAF 规则不适用于 LLM 语义攻击NIST SP 800-207 定义了零信任的核心理念——“永不信任，始终验证”（Never Trust, Always Verify）。2026 年 3 月，Microsoft 正式发布了 Zero Trust for AI（ZT4AI）参考架构，将零信任三原则——显式验证（Verify Explicitly）、最小权限（Use Least Privilege）、假设已遭入侵（Assume Breach）——扩展到了 AI 全生命周期。几乎同期，NVIDIA 发布了 Confidential AI Factory 参考架构，将机密计算（Confidential Computing）与零信任结合，通过硬件 TEE（Trusted Execution Environment）将信任边界从 Host OS 下推到 CPU/GPU 硬件层面。AI 基础设施安全演进的三个关键节点：传统边界安全 零信任网络 零信任 AI 基础设施 (2010-2020) (2020-2025) (2025-) │ │ │ ├── 防火墙+VPN ├── 微分段+mTLS ├── 机密容器+GPU TEE ├── 内网全信任 ├── 身份即边界 ├── 模型即边界 ├── 静态规则 ├── 动态策略 ├── AI 驱动策略 └── 人工响应 └── 半自动 SOAR └── 自主检测+响应为什么 AI 时代必须走向零信任？三个核心驱动力：算力资产的不可替代性：一台 8×H200 的 GPU 节点采购成本超过 30 万美元，其上的模型权重可能价值数千万美元（训练成本）。攻击者入侵一个推理 Pod 即可窃取完整权重——这在传统安全模型中是完全可能的，因为 Pod 内的 sidecar 容器默认不受东西向流量审查。推理数据的多租户混部：生产环境中，不同租户的推理请求可能路由到同一 GPU 节点的不同 MIG 分区。传统的 VLAN 隔离无法阻止一个租户通过 GPU 侧信道（如功耗分析、显存时序）推断另一租户的推理内容。攻击面的动态变化：AI 推理服务每周可能有数十次模型更新、镜像重建、拓扑变更。人工维护安全策略的速度远远跟不上——唯一可行的方案是将安全策略嵌入平台层，使其随基础设施自动演进。1.2 AI 基础设施的独特安全挑战与传统 Web 应用相比，AI 推理基础设施在安全上面临五类独特挑战：挑战一：GPU 内存的明文暴露在传统容器运行时（如 Docker/containerd）中，GPU 显存内容对宿主机 root 用户完全可见。通过nvidia-smi可以列出所有进程的显存使用，通过 CUDA Debug API 甚至可以 dump 显存内容。在模型推理过程中，权重矩阵在显存中以明文存储——这意味着任何一个获得宿主机 root 权限的攻击者，都可以完整窃取模型权重。挑战二：模型服务的东西向流量一个典型的 AI 推理请求链路涉及多个微服务：[客户端] → [API Gateway/Envoy] → [推理网关] → [vLLM Runtime] → [GPU Device Plugin] → [GPU] ↓ [模型缓存层/Redis] ↓ [监控导出/Prometheus]在这个链路中，API Gateway 到推理网关、推理网关到 vLLM Runtime、vLLM Runtime 到模型缓存层——这四段东西向流量在传统部署中均未加密。攻击者只需要在集群内部获得一个立足点（例如通过一个存在漏洞的 Jupyter Notebook 容器），即可嗅探全部推理流量。挑战三：模型供应链的信任传递一个生产推理服务依赖的软件供应链包括：组件典型来源信任风险基础镜像Docker Hub / NVIDIA NGC镜像被投毒、包含恶意层CUDA/cuDNN 运行时NVIDIA 官方源中间人替换、版本回退攻击vLLM/TGI 推理引擎PyPI / GitHub Release依赖混淆、Release 签名伪造模型权重文件Hugging Face / 私有存储权重被替换（缺乏完整性校验）自定义推理代码内部 Git 仓库代码审查绕过、硬编码密钥挑战四：推理请求的语义层攻击模型推理服务面临的不仅是传统的网络层攻击（DDoS、端口扫描），还有针对 LLM 的语义层攻击：Prompt Injection：将恶意指令嵌入用户输入，绕过系统提示词的安全约束Jailbreak：通过精心构造的对话上下文，使模型突破安全对齐Data Extraction：通过特定查询模式，诱导模型泄露训练数据中的 PIIModel Denial of Service：构造计算复杂度极高的推理请求（如要求生成长度为 128K 的序列），耗尽 GPU 算力传统 WAF 的签名匹配规则对这类攻击完全无效——因为它们不依赖已知的攻击模式，而是利用模型行为的固有特性。挑战五：可观测性的安全盲区AI 推理集群的可观测性栈（Prometheus + Grafana + GPU Exporter）通常关注性能指标——延迟、吞吐、GPU 利用率、显存占用。但以下安全关键指标往往缺失：推理请求的 Prompt 长度异常分布（可能指示 DoS 攻击）模型输出熵值的异常变化（可能指示权重被篡改）GPU 内核函数的非预期调用模式（可能指示侧信道攻击）容器内文件系统的非预期写入（可能指示后门植入）1.3 安全左移：平台工程的必然选择安全左移（Shift Left Security）的核心理念是将安全控制从生产运维阶段前移到开发和构建阶段——越早发现安全问题，修复成本越低。平台工程（Platform Engineering）则为安全左移提供了理想的载体：通过内部开发者平台（IDP）将安全门禁嵌入开发者工作流的每一个环节。在 AI 基础设施场景下，安全左移的具体含义是：安全控制点前移路径： 传统（右移） 左移后 修复成本对比 ───────────────────────────────────────────────────────────────────── 生产环境发现漏洞 → CI 流水线中被阻断 1:100 （传统修复成本 100×） 代码审查发现配置错误 → IDE 插件实时提示 1:10 上线后安全扫描 → 镜像构建时即扫描 1:50 人工渗透测试 → 自动化安全回归测试 1:30 事件响应 → 灰度发布+自动回滚 1:20平台工程实现安全左移的五个关键嵌入点：[开发者工作站] [CI 流水线] [镜像仓库] [K8S 集群] [运行时] │ │ │ │ │ ├── IDE 安全插件 ├── SAST/依赖扫描 ├── 镜像签名 ├── 准入控制 ├── 运行时检测 ├── Pre-commit Hook ├── IaC 安全扫描 ├── SBOM 生成 ├── 网络策略 ├── 异常行为分析 ├── 敏感信息检测 ├── 容器镜像扫描 ├── 漏洞数据库关联 ├── 资源配额 ├── eBPF 系统调用 └── 策略即文档 └── 策略合规检查 └── 签名验证 └── 运行时策略 └── 自动隔离2. 核心原理深度解析2.1 零信任 AI 基础设施的三大支柱零信任 AI 基础设施并非单一技术，而是由三个相互关联的支柱构成的体系。我将这三者称为"零信任 AI 基础设施的三角架构"：零信任 AI 基础设施 │ ├── [支柱一：身份与访问] │ ├── SPIRE/SPIFFE (工作负载身份) │ ├── OPA/Gatekeeper (策略即代码) │ ├── Workload Identity │ ├── JWT Token Review │ └── 动态 RBAC │ ├── [支柱二：网络与通信] │ ├── mTLS + Istio │ ├── Cilium NetworkPolicy │ ├── 微分段 (Microsegmentation) │ ├── eBPF 流量审计 │ └── L7 推理协议深度检查 │ └── [支柱三：工作负载与数据] ├── 机密容器 (CoCo) ├── TEE 可信执行 ├── Remote Attestation ├── 模型加密存储 └── 内存加密支柱一：身份与访问控制传统 Kubernetes RBAC 基于 ServiceAccount Token，但 Token 本身缺乏工作负载的身份证明——任何获得 Token 的容器都可以冒充该 ServiceAccount。SPIFFE（Secure Production Identity Framework for Everyone）通过 SPIFFE Verifiable Identity Document (SVID) 提供了密码学上可验证的工作负载身份。SPIRE（SPIFFE Runtime Environment）v1.11.0（2026 年 6 月最新版）的架构：[SPIRE Server] [SPIRE Agent] (每个节点一个) │ │ ├── 签发 SVID (X.509/JWT) ├── 节点本地 Unix Socket ├── 管理信任域 (Trust Domain) ├── 工作负载注册 (Workload Registration) ├── 对接外部 CA (Vault/CertManager) ├── 密钥/证书轮换 └── 联邦信任 (Federation) └── 工作负载 AttestationAI 推理场景下的 SPIFFE ID 设计示例：工作负载类型SPIFFE ID 格式权限边界vLLM 推理服务spiffe://ai-platform.prod/ns/inference/sa/vllm-server仅可访问模型存储和缓存模型下载 Sidecarspiffe://ai-platform.prod/ns/inference/sa/model-fetcher仅可读取模型仓库监控 Exporterspiffe://ai-platform.prod/ns/monitoring/sa/gpu-exporter仅可读取 GPU 指标调度器spiffe://ai-platform.prod/ns/kube-system/sa/ai-scheduler可读写调度决策OPA/Gatekeeper 策略执行流程：[API Server 请求] ↓ [认证 (Authentication)] ↓ [授权 (Authorization) ── RBAC] ↓ [准入控制 (Admission)] │ ├── Mutating Webhook ──→ 注入 Sidecar / 修改资源请求 │ └── Validating Webhook ──→ Gatekeeper (OPA) │ ├── 策略 1：镜像必须来自受信仓库 ├── 策略 2：必须设置 GPU 资源限制 ├── 策略 3：禁止 Privileged 容器 ├── 策略 4：必须声明 MIG 分区 ├── 策略 5：必须挂载信任的 ServiceAccount └── 策略 6：禁止挂载 HostPath支柱二：网络与通信安全零信任网络的核心原则是"默认拒绝，显式允许"——所有网络通信都需要明确授权，不存在隐式信任。AI 推理集群的微分段策略设计：[推理网关 (Inference Gateway)] │ ├──→ [vLLM Server :8000] 允许 ← gRPC 推理请求 ├──→ [Model Cache :6379] 允许 ← Redis 模型缓存查询 ├──→ [Control Plane :6443] 拒绝 ← 无理由访问 API Server └──→ [External :443] 拒绝 ← 无理由出站 [vLLM Server :8000] │ ├──→ [Model Storage :9000] 允许 ← 拉取模型权重 ├──→ [Shared Memory :shm] 允许 ← NCCL 集合通信 ├──→ [GPU Device Plugin :kubelet] 允许 ← GPU 分配 ├──→ [Other vLLM Pods] 拒绝 ← 默认隔离 └──→ [Internet] 拒绝 ← 禁止出站Cilium（v1.17.0，2026 年稳定版）通过 eBPF 实现了内核级网络策略执行，性能开销极低。对于 AI 推理场景的一个关键能力是L7 协议感知——不仅控制 IP:Port 级别通信，还能检查 HTTP/gRPC 的具体 API 路径：# CiliumNetworkPolicy: 推理 API 的 L7 访问控制apiVersion:cilium.io/v2kind:CiliumNetworkPolicymetadata:name:inference-api-policynamespace:inferencespec:endpointSelector:matchLabels:app:vllm-serveringress:-fromEndpoints:-matchLabels:app:inference-gatewaytoPorts:-ports:-port:"8000"protocol:TCPrules:http:-method:POSTpath:"/v1/completions"# 仅允许推理 API-method:POSTpath:"/v1/chat/completions"# 拒绝 /v1/models (模型列表泄露风险)# 拒绝 /health (可被用于存活探测扫描)支柱三：工作负载与数据安全机密容器（Confidential Containers, CoCo）将零信任的边界从操作系统层面下推到硬件层面。基于 Kata Containers v3.14.0 和 NVIDIA Confidential Computing 技术栈，AI 推理工作负载可以运行在硬件加密的 TEE 中——即使宿主机 root 也无法读取模型权重和推理数据。机密容器的信任边界对比：传统容器 机密容器 (CoCo) ───────── ──────────────── Trusted: Host OS + Hypervisor Untrusted: Host OS + Hypervisor Untrusted: 容器进程（相对） Trusted: 仅 TEE 内部（CPU TEE + GPU TEE） 信任根： Host OS Kernel 信任根： Hardware (CPU + GPU) 认证方式：容器命名空间隔离 认证方式：Remote Attestation (硬件密码学证明) Secret 保护：K8S Secret (etcd 明文) Secret 保护：KBS (Key Broker Service) + 加密内存Remote Attestation 流程（基于 RATS 架构）：[AI 推理容器 (TEE 内)]
