AI容器安全不是配個NetworkPolicy就完事了——鏡像被投毒、容器被逃逸、配置有缺陷任何一個短板都能讓整個集群淪陷。目錄一、你的AI容器真的安全嗎二、第一道防線鏡像簽名與驗證——讓假鏡像無處遁形2.1 為什么需要鏡像簽名2.2 主流工具對比Cosign vs Notation2.3 實戰Cosign Keyless 簽名 驗簽2.4 實戰Notation 企業CA簽名2.5 準入控制在K8s層面強制驗簽三、第二道防線鏡像掃描——在出事之前把漏洞揪出來3.1 鏡像掃描解決什么問題3.2 主流工具Trivy vs Grype3.3 實戰Trivy全量掃描 CI集成3.4 準入控制Trivy Operator 在K8s層自動掃描四、第三道防線RuntimeClass安全沙箱——用硬件隔離兜底4.1 為什么還需要沙箱4.2 RuntimeClass 安全沙箱方案4.3 實戰配置Kata Containers RuntimeClass4.4 gVisor配置參考五、第四道防線PodSecurity標準——從憑感覺到按標準5.1 PodSecurity的進化史5.2 實戰Enforce Warn Audit 三模式部署5.3 AI容器的Restricted配置示例六、分層防御總覽四道防線如何協同工作每一層的職責攻擊路徑與防御矩陣七、生產級完整YAML清單八、落地避坑指南8.1 不要一上來就全量推行8.2 關于性能損耗8.3 別忘了運行時監控九、總結一、你的AI容器真的安全嗎先問一個扎心的問題你公司用的AI推理鏡像是誰打的從哪個倉庫拉的打完有沒有被人改過如果你回答不上來那恭喜你——你已經踩進了容器安全最致命的坑。2025年的AI工程化浪潮里幾乎每家公司都在搶著上Kubernetes跑AI負載。模型推理用Pod拉起訓練用Job分布數據預處理用CronJob定時執行——看起來很美好對吧但現實是AI容器比普通業務容器更容易成為攻擊目標??鏡像投毒AI鏡像動輒幾個GB到十幾GB基礎鏡像里塞個挖礦腳本、改個Python依賴很難被發現。2024年就爆出過PyPI上的torch包被投毒事件那些鏡像如果被CI/CD流水線拉下來直接推生產……??逃逸攻擊AI推理需要GPU直通、需要掛載大容量存儲權限難免放寬。一旦有攻擊者通過模型文件注入觸發容器逃逸宿主機的GPU顯存數據、模型權重文件全暴露。??配置缺陷大部分AI團隊focus在模型精度上寫出來的K8s YAML就倆字——奔放。privileged: true、hostNetwork、hostPath——比你家大門還敞亮。我見過一個真實的案例某AI公司的推理Pod直接用root跑掛載了宿主機的docker.sock結果一個模型輸入層面的RCE就讓攻擊者拿到整個集群的控制權——代價是全公司的模型參數被勒索損失七位數。所以容器安全從來不是配一個NetworkPolicy就完事那么簡單。今天這篇咱們就聊聊AI容器安全的四道縱深防線——從鏡像供應鏈到運行時隔離從Pod準入到策略管控每一道都是一層過濾網層層遞進、環環相扣。二、第一道防線鏡像簽名與驗證——讓假鏡像無處遁形2.1 為什么需要鏡像簽名很多人覺得“鏡像我都是從官方倉庫拉的能有什么問題”問得好那我再問一句你能保證從拉取到部署的整個鏈條上沒人動過這個鏡像嗎Docker Hub上的鏡像是沒有天然防篡改能力的。你拉下來的鏡像是一個tar包推上去的中間經過的鏡像倉庫是否可信鏡像Tag是否被覆蓋過CI/CD流水線的構建機如果被攻破推送的鏡像是否被篡改鏡像簽名的本質用私鑰對鏡像的digest簽名任何人只要有公鑰就能驗證鏡像的完整性和來源可靠性。誰簽的名、鏡像內容變沒變、什么時間簽的——三個問題一次性回答。2.2 主流工具對比Cosign vs Notation目前鏡像簽名領域兩個主流工具二選一維度CosignNotation締造者Sigstore 社區CNCF Notary 項目簽名載體OCI 鏡像倉庫的 Tag 或 ReferrersOCI Artifact / ReferrersKey管理支持 KeylessOIDC 免密鑰 傳統 Key傳統 Key 證書鏈模式認證集成原生支持 GitHub/GitLab OIDC支持 x509 證書策略引擎Cosign Policy 內置Ratify 獨立組件企業友好度??? Keyless 模式降低門檻???? 證書鏈適合企業CA體系社區活躍度非常高Sigstore 社區主力較高CNCF 賽道選型建議如果你在GitHub/GitLab上的CI/CD用的是OIDC認證強烈建議走Cosign的Keyless模式。這東西是真的省心——連密鑰管理都省了OIDC令牌本身就是你的身份憑證。如果貴司有嚴格的PKI體系比如基于企業CA簽發的證書Notation會更適合。2.3 實戰Cosign Keyless 簽名 驗簽先說Keyless模式——這是Cosign最大的亮點# 安裝 Cosign # Mac brew install cosign # Linux # 這里走 VERSION 變量指定版本 VERSION$(curl -s https://api.github.com/repos/sigstore/cosign/releases/latest | jq -r .tag_name | sed s/^v//) curl -LO https://github.com/sigstore/cosign/releases/download/v${VERSION}/cosign_${VERSION}_amd64.deb sudo dpkg -i cosign_${VERSION}_amd64.deb # 構建并推送鏡像 docker build -t registry.example.com/ai-inference:v1 . docker push registry.example.com/ai-inference:v1 # 簽名Keyless模式不用管理任何密鑰 cosign sign registry.example.com/ai-inference:v1 # 觸發瀏覽器OIDC認證或通過環境變量指配CI的OIDC token # COSIGN_EXPERIMENTAL1 cosign sign ... # 完成后簽名信息作為OCI Tag或Referrers存儲在鏡像倉庫中驗證簽名# 驗證簽名 cosign verify \ --certificate-identity-regexp https://github.com/myorg/.* \ --certificate-oidc-issuer-regexp https://token.actions.githubusercontent.com \ registry.example.com/ai-inference:v1??關鍵配置點--certificate-identity-regexp和--certificate-oidc-issuer-regexp定義了誰的簽名我認。這里必須精確匹配你組織的CI系統否則任何人都能用Cosign簽你的鏡像——那就失去意義了。2.4 實戰Notation 企業CA簽名# 安裝 Notation # Mac brew install notation # Linux curl -LO https://github.com/notaryproject/notation/releases/latest/download/notation_1.1.0_linux_amd64.tar.gz tar -xzf notation_*.tar.gz sudo mv notation /usr/local/bin/ # 導入企業CA簽發的證書 notation cert add --type ca --file ca.pem --name my-enterprise-ca notation cert add --type signing --file signer-cert.pem --key signer-key.pem \ --name ai-team-key # 簽名 notation sign registry.example.com/ai-inference:v1 \ --signature-format cose \ --key ai-team-key # 本地驗證 notation verify registry.example.com/ai-inference:v12.5 準入控制在K8s層面強制驗簽光簽名沒有任何意義只有在部署時強制驗證才有用。用RatifyNotation的策略執行引擎或Kyverno做準入控制核心邏輯在K8s的Admission Webhook里攔截所有Pod創建請求檢查鏡像是否有有效簽名。沒有簽名 → 直接拒絕創建。# Kyverno 策略強制所有Pod必須包含已驗證簽名的鏡像 apiVersion: kyverno.io/v1 kind: ClusterPolicy metadata: name: require-image-signature spec: validationFailureAction: Enforce background: false rules: - name: check-cosign-signature match: any: - resources: kinds: - Pod verifyImages: - imageReferences: - registry.example.com/* mutateDigest: true verifyDigest: true required: true attestors: - count: 1 entries: - keys: publicKeys: |- -----BEGIN PUBLIC KEY----- MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE... -----END PUBLIC KEY-----為什么不推薦用 Admission Controller 手動寫Webhook因為Kyverno/ Ratify/ OPA Gatekeeper 已經封裝了鏡像簽名驗證的完整邏輯沒必要再重復造輪子。而且它們支持熱更新策略規則不需要重啟APIServer。三、第二道防線鏡像掃描——在出事之前把漏洞揪出來3.1 鏡像掃描解決什么問題鏡像簽名解決的是這個鏡像有沒有被篡改而鏡像掃描解決的是這個鏡像本身有沒有漏洞。??這是兩道完全不同的防線。簽名保證完整性掃描保證安全性。少了任何一個你的供應鏈安全都有窟窿。3.2 主流工具Trivy vs Grype維度TrivyGrype開發商Aqua SecurityAnchore漏洞庫自家 NVD RedHat Alpine 等14個源自家 NVD RedHat Ubuntu 等掃描速度???? 非常快??? 較快SBOM支持CycloneDX SPDXCycloneDX SPDX策略引擎內置 Cosign 配置策略需要 Syft 配合容器鏡像層緩存??當前不支持K8s 集成Trivy OperatorCRD 準入社區方案我的推薦日常開發用Trivy就夠了。理由很直接——Trivy Operator可以做成CRD掃描K8s集群中所有Pod的鏡像跟K8s生態綁定最緊密不用額外運維一套掃描系統。3.3 實戰Trivy全量掃描 CI集成# 安裝 Trivy # Mac brew install trivy # Linux curl -sfL https://raw.githubusercontent.com/aquasecurity/trivy/main/contrib/install.sh | sh # 掃描單個鏡像 trivy image registry.example.com/ai-inference:v1 # 掃描并輸出JSON供后續處理 trivy image --format json --output scan-result.json \ registry.example.com/ai-inference:v1 # 只掃描 HIGH / CRITICAL 級別建議CI用這種模式 trivy image --severity HIGH,CRITICAL \ --exit-code 1 \ --ignore-unfixed \ registry.example.com/ai-inference:v1??必配參數說明--exit-code 1發現漏洞時讓CI失敗阻止有問題的鏡像進入倉庫--ignore-unfixed忽略沒有修復方案的漏洞很多OS包漏洞確實沒有補丁掃出來也沒用白白阻塞流水線--severity HIGH,CRITICAL只關心中高風險LOW/MEDIUM級別的漏洞閾值下可以放過3.4 準入控制Trivy Operator 在K8s層自動掃描Trivy Operator是精品——它作為Operator運行在集群內自動發現并掃描所有Pod的鏡像同時提供Admission Controller準入Webhook在Pod創建前自動掃描# 安裝 Trivy Operator helm repo add aqua https://aquasecurity.github.io/helm-charts helm repo update helm install trivy-operator aqua/trivy-operator \ --namespace trivy-system \ --create-namespace \ --settrivy.ignoreUnfixedtrue \ --settrivy.severityCRITICAL,HIGH然后Trivy Operator會自動創建VulnerabilityReportCRD每個Pod都會有一個對應的掃描報告# 查看所有漏洞報告 kubectl get vulnerabilityreports -A # 查看某個Pod的詳細漏洞 kubectl get vulnerabilityreport pod-ai-inference-xxxxx -o yaml如果再配合準入Webhook所有新創建的Pod如果不滿足漏洞閾值直接拒絕# 準入策略拒絕包含CRITICAL漏洞的鏡像 apiVersion: aquasecurity.github.io/v1alpha1 kind: ClusterConfigAuditReport ... # 這里實際上是通過Trivy Operator的ConfigMap配置策略 # 在 trivy-operator 命名空間修改配置即可 kubectl edit configmap trivy-operator -n trivy-system四、第三道防線RuntimeClass安全沙箱——用硬件隔離兜底4.1 為什么還需要沙箱前兩道防線解決的是供應鏈安全——鏡像是否可信、是否有漏洞。但它們解決不了運行時逃逸的問題。只要你的容器和宿主機共享Linux內核這是Docker和runc的默認模式就有逃逸的可能——CVE-2022-0185Linux內核越界漏洞、CVE-2024-21626runc文件描述符泄露……每年的逃逸漏洞輪著來。??AI容器的特殊性AI推理Pod需要掛載GPU、請求巨量顯存、可能掛載額外的模型存儲。這些特權操作天然增加了逃逸攻擊面。4.2 RuntimeClass 安全沙箱方案K8s的RuntimeClass機制就是為解決這個問題的——讓不同的Pod跑在不同的容器運行時上。核心思路高風險的AI推理Pod跑在輕量級VM沙箱里跟宿主機完全隔離。維度Kata ContainersgVisor隔離級別輕量級VM硬件虛擬化用戶態內核應用層攔截性能損耗~5-10%接近原生~15-40%系統調用越多越慢GPU支持? 完整支持GPU passthrough? 不支持GPU直通兼容性????? 所有系統調用都支持??? 部分系統調用不兼容啟動速度較慢需啟動VM很快進程級安全等級更高硬件隔離較高軟件隔離適用場景AI推理、GPU負載、高風險Pod通用Web服務、低風險PodAI場景的明確建議AI推理Pod用Kata Containers——GPU passthrough是剛需沒有替代方案。損失5-10%的性能換的是完整的硬件隔離。Web服務 / 數據處理Pod用gVisor——不需要GPU系統調用模式簡單gVisor足夠。管理面Podkube-system下的組件用默認runc——改運行時可能導致兼容性問題。4.3 實戰配置Kata Containers RuntimeClass# 1. 安裝Kata Containers選擇一個節點做測試 # Ubuntu sudo apt-get update sudo apt-get install -y kata-containers # 2. 配置 containerd 支持 Kata # 編輯 /etc/containerd/config.toml 添加 cat /etc/containerd/config.toml EOF [plugins.io.containerd.grpc.v1.cri.containerd.runtimes.kata] runtime_type io.containerd.kata.v2 privileged_without_host_devices true EOF # 重啟 containerd sudo systemctl restart containerd # 3. 創建 RuntimeClass cat EOF | kubectl apply -f - apiVersion: node.k8s.io/v1 kind: RuntimeClass metadata: name: kata-qemu handler: kata scheduling: nodeSelector: katacontainers.io/kata-runtime: true EOF # 4. 標記kata節點 kubectl label node ai-node-name katacontainers.io/kata-runtimetrue # 5. 在AI推理Pod中指定 runtimeClassName apiVersion: v1 kind: Pod metadata: name: ai-inference-safe spec: runtimeClassName: kata-qemu containers: - name: inference image: registry.example.com/ai-inference:v1 resources: requests: nvidia.com/gpu: 1 limits: nvidia.com/gpu: 1 volumeMounts: - name: model-storage mountPath: /models volumes: - name: model-storage persistentVolumeClaim: claimName: model-pvc??注意事項啟用Kata的節點建議打上taint只調度安全Pod避免非安全Pod也跑到Kata節點上浪費資源GPU passthrough需要節點支持SR-IOV或直通不是所有硬件都支持Kata對存儲有額外的Overhead建議用local SSD而非網絡存儲4.4 gVisor配置參考# 安裝 gVisor runsc curl -LO https://storage.googleapis.com/gvisor/releases/release/latest/x86_64/runsc sudo mv runsc /usr/local/bin/ sudo chmod x /usr/local/bin/runsc # 配置 containerd cat /etc/containerd/config.toml EOF [plugins.io.containerd.grpc.v1.cri.containerd.runtimes.runsc] runtime_type io.containerd.runsc.v1 EOF sudo systemctl restart containerd # 創建 RuntimeClass cat EOF | kubectl apply -f - apiVersion: node.k8s.io/v1 kind: RuntimeClass metadata: name: gvisor handler: runsc EOF五、第四道防線PodSecurity標準——從憑感覺到按標準5.1 PodSecurity的進化史PodSecurity PoliciesPSP那會兒是真的反人類——一個PSP寫200行YAML是常事而且邏輯復雜到連K8s大佬都配不對。好在K8s v1.21開始引入PodSecurity Admissionv1.25正式GA把PSP替代了。PodSecurity標準只有三個等級但覆蓋了95%以上的容器安全配置等級說明典型限制Privileged不受限——啥都能干沒有額外限制Baseline最小受限——防已知特權升級禁止privileged、禁止hostNetwork、禁止hostPID/IPC、限制Seccomp等Restricted強受限——遵循Pod安全最佳實踐Baseline基礎上強制non-root、限制capabilities、限制SELinux等實際建議你的集群中90%的Pod都應該用Restricted只有那些實在不兼容的特殊Pod比如網絡插件、監控agent才放寬到Baseline或Privileged。5.2 實戰Enforce Warn Audit 三模式部署PodSecurity采用三種模式而非一刀切讓你可以漸進式落地# 命名空間級別配置 apiVersion: v1 kind: Namespace metadata: name: ai-inference-prod labels: # Enforce直接拒絕不符合Restricted的Pod pod-security.kubernetes.io/enforce: restricted pod-security.kubernetes.io/enforce-version: latest # Warn不符合的Pod創建時給警告但不會拒絕 pod-security.kubernetes.io/warn: baseline pod-security.kubernetes.io/warn-version: latest # Audit不符合的在審計日志記錄但沒有任何用戶可見影響 pod-security.kubernetes.io/audit: baseline pod-security.kubernetes.io/audit-version: latest --- # 集群級默認值 apiVersion: apiserver.config.k8s.io/v1 kind: AdmissionConfiguration plugins: - name: PodSecurity configuration: apiVersion: pod-security.admission.config.k8s.io/v1 kind: PodSecurityConfiguration defaults: enforce: restricted enforce-version: latest audit: baseline audit-version: latest warn: baseline warn-version: latest exemptions: # 豁免kube-system等系統命名空間 namespaces: [kube-system, gatekeeper-system, trivy-system] # 豁免特定運行時類 runtimeClasses: [kata-qemu, gvisor]5.3 AI容器的Restricted配置示例apiVersion: apps/v1 kind: Deployment metadata: name: ai-inference-secure namespace: ai-inference-prod spec: replicas: 3 selector: matchLabels: app: ai-inference template: metadata: labels: app: ai-inference spec: # 使用Kata運行時——第三道防線 runtimeClassName: kata-qemu securityContext: # 關鍵Pod級別的安全上下文 runAsNonRoot: true runAsUser: 1000 runAsGroup: 3000 fsGroup: 2000 seccompProfile: type: RuntimeDefault containers: - name: inference image: registry.example.com/ai-inference:v1 securityContext: allowPrivilegeEscalation: false capabilities: drop: - ALL # AI推理可能需要CAP_SYS_PTRACE按需添加 # add: [SYS_PTRACE] readOnlyRootFilesystem: true runAsNonRoot: true runAsUser: 1000 seccompProfile: type: RuntimeDefault resources: requests: memory: 8Gi cpu: 4 nvidia.com/gpu: 1 limits: memory: 16Gi cpu: 8 nvidia.com/gpu: 1 volumeMounts: - name: tmp mountPath: /tmp - name: models mountPath: /models readOnly: true volumes: - name: tmp emptyDir: {} - name: models persistentVolumeClaim: claimName: ai-models-pvc readOnly: true??常見踩坑點readOnlyRootFilesystem: true會導致應用在根目錄寫臨時文件失敗。必須聲明emptyDir來掛載/tmp和/var/tmp等寫目錄。runAsNonRoot: truerunAsUser: 1000必須確保鏡像內的進程是用1000uid跑的。如果Dockerfile里用root啟動這里直接創建失敗。AI推理框架如Triton Server有自己的進程管理邏輯要注意這些框架的安全配置兼容性。六、分層防御總覽四道防線如何協同工作下面的圖展示了AI容器從提交到運行的完整防御鏈路flowchart TD subgraph 開發者側 A[代碼提交] -- B[CI流水線] B -- C[Trivy鏡像掃描] C -- D{漏洞達標?} D --|否| E[阻斷-返回修復] D --|是| F[Cosign/Notation簽名] F -- G[推送鏡像到倉庫] end subgraph K8s集群側 H[創建Pod請求] -- I[Admission Webhook] I -- J[Ratify/Kyverno驗簽] J -- K{簽名有效?} K --|否| L[拒絕Pod創建] K --|是| M[PodSecurity校驗] M -- N{符合Restricted?} N --|否| O[Warn/Reject] N --|是| P[Pod調度] P -- Q{Schedule調度策略} Q --|AI推理Pod| R[RuntimeClass:kata-qemu] Q --|Web服務Pod| S[RuntimeClass:gvisor] Q --|系統組件| T[默認runc] end subgraph 運行時 R -- U[Kata輕量級VM隔離] S -- V[gVisor用戶態內核] T -- W[標準容器] U -- X{運行時監控} V -- X W -- X X -- Y[Falco/告警] end每一層的職責防線防御對象生命周期階段核心工具繞過成本①鏡像簽名與驗證鏡像篡改、供應鏈攻擊構建→部署Cosign/Notation Ratify/Kyverno攻破私鑰/CA或繞過Admission②鏡像掃描已知漏洞、惡意依賴構建時 運行時持續Trivy/Grype Trivy Operator漏洞不上報或掩蓋特征③RuntimeClass沙箱容器逃逸、內核漏洞運行時Kata Containers / gVisor逃出VM或突破Seccomp④PodSecurity標準配置缺陷、過度特權部署準入PodSecurity Admission找到豁免條件或利用不兼容點攻擊路徑與防御矩陣下面的Mermaid圖直觀展示了四類典型攻擊分別會被哪道防線攔截——紅色劃線表示被攔截綠色勾表示可繞過需要更上游防線兜底flowchart LR subgraph 攻擊向量 A1[惡意鏡像投毒] A2[供應鏈依賴篡改] A3[內核漏洞逃逸] A4[容器過度特權] end subgraph 防線攔截 L1[①鏡像簽名驗證] L2[②漏洞掃描] L3[③RuntimeClass沙箱] L4[④PodSecurity標準] end subgraph 攔截結果 R1[? 攔截 - 簽名不匹配] R2[? 攔截 - CVE超閾值] R3[? 攔截 - VM隔離] R4[? 攔截 - Restricted策略] R5[?? 需要⑤運行時監控兜底] end A1 --|鏡像digest不一致| L1 L1 --|驗簽失敗| R1 A2 --|依賴含已知漏洞| L2 L2 --|CRITICAL漏洞| R2 A3 --|利用內核syscall| L3 L3 --|Kata硬件虛擬機| R3 A3 -.-|突破沙箱| R5 A4 --|特權操作被限制| L4 L4 --|非root只讀FS| R4攻擊類型繞過第一道繞過第二道繞過第三道繞過第四道惡意鏡像投毒? 簽名驗證? 漏洞掃描? 無法阻止? 無法阻止供應鏈依賴篡改? 簽名驗證? 漏洞掃描? 無法阻止? 無法阻止內核漏洞逃逸? 簽名有效即可? 能過掃描? Kata VM隔離? 非內核級問題容器過度特權? 簽名有效即可? 能過掃描? 縮小攻擊面? Restricted策略宿主文件訪問? 簽名有效即可? 能過掃描? Kata文件系統隔離? 只讀根文件系統網絡橫向移動? 簽名有效即可? 能過掃描? 沙箱內仍可網絡通信? 無直接防御七、生產級完整YAML清單下面是一份可以直接用于生產環境的完整配置組合# 文件1RuntimeClass 定義 --- apiVersion: node.k8s.io/v1 kind: RuntimeClass metadata: name: kata-qemu handler: kata scheduling: nodeSelector: katacontainers.io/kata-runtime: true tolerations: - effect: NoSchedule key: kata operator: Exists --- apiVersion: node.k8s.io/v1 kind: RuntimeClass metadata: name: gvisor handler: runsc --- # 文件2命名空間級PodSecurity配置 apiVersion: v1 kind: Namespace metadata: name: ai-inference-prod labels: pod-security.kubernetes.io/enforce: restricted pod-security.kubernetes.io/enforce-version: latest pod-security.kubernetes.io/warn: baseline pod-security.kubernetes.io/warn-version: latest --- apiVersion: v1 kind: Namespace metadata: name: ai-training labels: # Training可能用GPU集合通信放寬到baseline pod-security.kubernetes.io/enforce: baseline pod-security.kubernetes.io/enforce-version: latest --- # 文件3Kyverno鏡像簽名驗證策略 apiVersion: kyverno.io/v1 kind: ClusterPolicy metadata: name: require-image-signature spec: validationFailureAction: Enforce background: false rules: - name: check-signature match: any: - resources: kinds: - Pod verifyImages: - imageReferences: - registry.example.com/* mutateDigest: true verifyDigest: true required: true attestors: - count: 1 entries: - keys: publicKeys: |- -----BEGIN PUBLIC KEY----- MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEX... -----END PUBLIC KEY----- --- # 文件4生產級AI推理Deployment完整安全配置 apiVersion: apps/v1 kind: Deployment metadata: name: ai-inference-secure namespace: ai-inference-prod labels: app.kubernetes.io/name: ai-inference app.kubernetes.io/component: inference-server security-tier: restricted spec: replicas: 3 selector: matchLabels: app: ai-inference template: metadata: labels: app: ai-inference annotations: # 顯式聲明容器運行時 container.apparmor.security.beta.kubernetes.io/inference: runtime/default seccomp.security.alpha.kubernetes.io/pod: runtime/default spec: runtimeClassName: kata-qemu serviceAccountName: inference-sa securityContext: runAsNonRoot: true runAsUser: 1000 runAsGroup: 3000 fsGroup: 2000 seccompProfile: type: RuntimeDefault containers: - name: inference image: registry.example.com/ai-inference:v1 imagePullPolicy: Always ports: - containerPort: 8000 protocol: TCP env: - name: MODEL_PATH value: /models/current - name: LOG_LEVEL value: info securityContext: allowPrivilegeEscalation: false capabilities: drop: - ALL readOnlyRootFilesystem: true runAsNonRoot: true runAsUser: 1000 seccompProfile: type: RuntimeDefault resources: requests: cpu: 4 memory: 8Gi nvidia.com/gpu: 1 limits: cpu: 8 memory: 16Gi nvidia.com/gpu: 1 volumeMounts: - name: tmp mountPath: /tmp - name: model-storage mountPath: /models readOnly: true livenessProbe: httpGet: path: /health port: 8000 initialDelaySeconds: 30 periodSeconds: 10 readinessProbe: httpGet: path: /ready port: 8000 initialDelaySeconds: 5 periodSeconds: 5 volumes: - name: tmp emptyDir: medium: Memory sizeLimit: 1Gi - name: model-storage persistentVolumeClaim: claimName: ai-models-pvc readOnly: true --- # 文件5最小RBAC apiVersion: v1 kind: ServiceAccount metadata: name: inference-sa namespace: ai-inference-prod automountServiceAccountToken: false --- # 文件6NetworkPolicy apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: inference-network-policy namespace: ai-inference-prod spec: podSelector: matchLabels: app: ai-inference policyTypes: - Ingress - Egress ingress: - from: - namespaceSelector: matchLabels: kubernetes.io/metadata.name: ai-gateway ports: - port: 8000 protocol: TCP egress: - to: - namespaceSelector: matchLabels: kubernetes.io/metadata.name: kube-system ports: - port: 53 protocol: UDP - port: 53 protocol: TCP - to: - podSelector: matchLabels: app: model-registry ports: - port: 50051 protocol: TCP八、落地避坑指南8.1 不要一上來就全量推行我見過太多團隊“我們在所有命名空間強制enforce: restricted” 然后……所有人都被阻塞了然后……策略被回滾了。建議的落地節奏第1周所有命名空間用audit模式觀察哪些Pod不滿足第2周對不滿足的Pod逐個評估要么改代碼適應Restricted要么確認豁免第3周核心業務命名空間切到enforce: restricted第4周全量切enforce: restricted保留warn: baseline作為新風向標8.2 關于性能損耗??不要無腦對所有Pod啟用Kata Containers。Kata的VM啟動開銷在5-20秒之間對于水平擴展頻繁匹配Pod的應用這個延遲是不可接受的。而且不是所有CPU都支持Kata需要的虛擬化擴展Intel VT-x/AMD-V。合理策略高風險AI推理Pod → Kata安全 性能批處理/離線任務 → Kata可接受額外啟動時間在線Web服務 → gVisor啟動快隔離夠用kube-system組件 → runc不改運行時8.3 別忘了運行時監控四道防線都配好了但你以為就完事了運行時監控是第五道防線可選增強# Falco 運行時安全作為補充監控 helm repo add falcosecurity https://falcosecurity.github.io/charts helm install falco falcosecurity/falco \ --namespace falco \ --create-namespace \ --set falco.driver.kindebpfFalco可以檢測容器內執行shell、讀取敏感文件、創建網絡連接等等——即使攻擊者突破了Kata沙箱Falco還能在宿主機層給你報警。九、總結AI容器安全不是選一個工具就能解決的。四道防線缺一不可鏡像簽名Cosign/Notation→ 解決鏡像被篡改的問題鏡像掃描Trivy/Grype→ 解決鏡像有漏洞的問題RuntimeClass沙箱Kata/gVisor→ 解決逃逸攻擊的問題PodSecurity標準Restricted/Baseline→ 解決配置缺陷的問題配置從來不是為了阻止絕對不會出事——而是為了提高攻擊成本讓攻擊者覺得不值得攻破你。今天花半天配好這四道防線明天省下的可能是一個七位數的安全事件。 推薦閱讀Cosign 官方文檔Trivy Operator 項目Kata Containers 架構說明K8s PodSecurity 標準如果你也在做AI容器安全歡迎留言交流 你覺得哪道防線最難落地標簽容器安全鏡像簽名RuntimeClassPodSecurityKata ContainersCosignTrivy