AI容器安全不是配個(gè)NetworkPolicy就完事了——鏡像被投毒、容器被逃逸、配置有缺陷任何一個(gè)短板都能讓整個(gè)集群淪陷。目錄一、你的AI容器真的安全嗎二、第一道防線鏡像簽名與驗(yàn)證——讓假鏡像無(wú)處遁形2.1 為什么需要鏡像簽名2.2 主流工具對(duì)比Cosign vs Notation2.3 實(shí)戰(zhàn)Cosign Keyless 簽名 驗(yàn)簽2.4 實(shí)戰(zhàn)Notation 企業(yè)CA簽名2.5 準(zhǔn)入控制在K8s層面強(qiáng)制驗(yàn)簽三、第二道防線鏡像掃描——在出事之前把漏洞揪出來(lái)3.1 鏡像掃描解決什么問(wèn)題3.2 主流工具Trivy vs Grype3.3 實(shí)戰(zhàn)Trivy全量掃描 CI集成3.4 準(zhǔn)入控制Trivy Operator 在K8s層自動(dòng)掃描四、第三道防線RuntimeClass安全沙箱——用硬件隔離兜底4.1 為什么還需要沙箱4.2 RuntimeClass 安全沙箱方案4.3 實(shí)戰(zhàn)配置Kata Containers RuntimeClass4.4 gVisor配置參考五、第四道防線PodSecurity標(biāo)準(zhǔn)——從憑感覺(jué)到按標(biāo)準(zhǔn)5.1 PodSecurity的進(jìn)化史5.2 實(shí)戰(zhàn)Enforce Warn Audit 三模式部署5.3 AI容器的Restricted配置示例六、分層防御總覽四道防線如何協(xié)同工作每一層的職責(zé)攻擊路徑與防御矩陣七、生產(chǎn)級(jí)完整YAML清單八、落地避坑指南8.1 不要一上來(lái)就全量推行8.2 關(guān)于性能損耗8.3 別忘了運(yùn)行時(shí)監(jiān)控九、總結(jié)一、你的AI容器真的安全嗎先問(wèn)一個(gè)扎心的問(wèn)題你公司用的AI推理鏡像是誰(shuí)打的從哪個(gè)倉(cāng)庫(kù)拉的打完有沒(méi)有被人改過(guò)如果你回答不上來(lái)那恭喜你——你已經(jīng)踩進(jìn)了容器安全最致命的坑。2025年的AI工程化浪潮里幾乎每家公司都在搶著上Kubernetes跑AI負(fù)載。模型推理用Pod拉起訓(xùn)練用Job分布數(shù)據(jù)預(yù)處理用CronJob定時(shí)執(zhí)行——看起來(lái)很美好對(duì)吧但現(xiàn)實(shí)是AI容器比普通業(yè)務(wù)容器更容易成為攻擊目標(biāo)??鏡像投毒AI鏡像動(dòng)輒幾個(gè)GB到十幾GB基礎(chǔ)鏡像里塞個(gè)挖礦腳本、改個(gè)Python依賴很難被發(fā)現(xiàn)。2024年就爆出過(guò)PyPI上的torch包被投毒事件那些鏡像如果被CI/CD流水線拉下來(lái)直接推生產(chǎn)……??逃逸攻擊AI推理需要GPU直通、需要掛載大容量存儲(chǔ)權(quán)限難免放寬。一旦有攻擊者通過(guò)模型文件注入觸發(fā)容器逃逸宿主機(jī)的GPU顯存數(shù)據(jù)、模型權(quán)重文件全暴露。??配置缺陷大部分AI團(tuán)隊(duì)focus在模型精度上寫(xiě)出來(lái)的K8s YAML就倆字——奔放。privileged: true、hostNetwork、hostPath——比你家大門(mén)還敞亮。我見(jiàn)過(guò)一個(gè)真實(shí)的案例某AI公司的推理Pod直接用root跑掛載了宿主機(jī)的docker.sock結(jié)果一個(gè)模型輸入層面的RCE就讓攻擊者拿到整個(gè)集群的控制權(quán)——代價(jià)是全公司的模型參數(shù)被勒索損失七位數(shù)。所以容器安全從來(lái)不是配一個(gè)NetworkPolicy就完事那么簡(jiǎn)單。今天這篇咱們就聊聊AI容器安全的四道縱深防線——從鏡像供應(yīng)鏈到運(yùn)行時(shí)隔離從Pod準(zhǔn)入到策略管控每一道都是一層過(guò)濾網(wǎng)層層遞進(jìn)、環(huán)環(huán)相扣。二、第一道防線鏡像簽名與驗(yàn)證——讓假鏡像無(wú)處遁形2.1 為什么需要鏡像簽名很多人覺(jué)得“鏡像我都是從官方倉(cāng)庫(kù)拉的能有什么問(wèn)題”問(wèn)得好那我再問(wèn)一句你能保證從拉取到部署的整個(gè)鏈條上沒(méi)人動(dòng)過(guò)這個(gè)鏡像嗎Docker Hub上的鏡像是沒(méi)有天然防篡改能力的。你拉下來(lái)的鏡像是一個(gè)tar包推上去的中間經(jīng)過(guò)的鏡像倉(cāng)庫(kù)是否可信鏡像Tag是否被覆蓋過(guò)CI/CD流水線的構(gòu)建機(jī)如果被攻破推送的鏡像是否被篡改鏡像簽名的本質(zhì)用私鑰對(duì)鏡像的digest簽名任何人只要有公鑰就能驗(yàn)證鏡像的完整性和來(lái)源可靠性。誰(shuí)簽的名、鏡像內(nèi)容變沒(méi)變、什么時(shí)間簽的——三個(gè)問(wèn)題一次性回答。2.2 主流工具對(duì)比Cosign vs Notation目前鏡像簽名領(lǐng)域兩個(gè)主流工具二選一維度CosignNotation締造者Sigstore 社區(qū)CNCF Notary 項(xiàng)目簽名載體OCI 鏡像倉(cāng)庫(kù)的 Tag 或 ReferrersOCI Artifact / ReferrersKey管理支持 KeylessOIDC 免密鑰 傳統(tǒng) Key傳統(tǒng) Key 證書(shū)鏈模式認(rèn)證集成原生支持 GitHub/GitLab OIDC支持 x509 證書(shū)策略引擎Cosign Policy 內(nèi)置Ratify 獨(dú)立組件企業(yè)友好度??? Keyless 模式降低門(mén)檻???? 證書(shū)鏈適合企業(yè)CA體系社區(qū)活躍度非常高Sigstore 社區(qū)主力較高CNCF 賽道選型建議如果你在GitHub/GitLab上的CI/CD用的是OIDC認(rèn)證強(qiáng)烈建議走Cosign的Keyless模式。這東西是真的省心——連密鑰管理都省了OIDC令牌本身就是你的身份憑證。如果貴司有嚴(yán)格的PKI體系比如基于企業(yè)CA簽發(fā)的證書(shū)Notation會(huì)更適合。2.3 實(shí)戰(zhàn)Cosign Keyless 簽名 驗(yàn)簽先說(shuō)Keyless模式——這是Cosign最大的亮點(diǎn)# 安裝 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 # 構(gòu)建并推送鏡像 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 # 觸發(fā)瀏覽器OIDC認(rèn)證或通過(guò)環(huán)境變量指配CI的OIDC token # COSIGN_EXPERIMENTAL1 cosign sign ... # 完成后簽名信息作為OCI Tag或Referrers存儲(chǔ)在鏡像倉(cāng)庫(kù)中驗(yàn)證簽名# 驗(yàn)證簽名 cosign verify \ --certificate-identity-regexp https://github.com/myorg/.* \ --certificate-oidc-issuer-regexp https://token.actions.githubusercontent.com \ registry.example.com/ai-inference:v1??關(guān)鍵配置點(diǎn)--certificate-identity-regexp和--certificate-oidc-issuer-regexp定義了誰(shuí)的簽名我認(rèn)。這里必須精確匹配你組織的CI系統(tǒng)否則任何人都能用Cosign簽?zāi)愕溺R像——那就失去意義了。2.4 實(shí)戰(zhàn)Notation 企業(yè)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/ # 導(dǎo)入企業(yè)CA簽發(fā)的證書(shū) 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 # 本地驗(yàn)證 notation verify registry.example.com/ai-inference:v12.5 準(zhǔn)入控制在K8s層面強(qiáng)制驗(yàn)簽光簽名沒(méi)有任何意義只有在部署時(shí)強(qiáng)制驗(yàn)證才有用。用RatifyNotation的策略執(zhí)行引擎或Kyverno做準(zhǔn)入控制核心邏輯在K8s的Admission Webhook里攔截所有Pod創(chuàng)建請(qǐng)求檢查鏡像是否有有效簽名。沒(méi)有簽名 → 直接拒絕創(chuàng)建。# Kyverno 策略強(qiáng)制所有Pod必須包含已驗(yàn)證簽名的鏡像 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 手動(dòng)寫(xiě)Webhook因?yàn)镵yverno/ Ratify/ OPA Gatekeeper 已經(jīng)封裝了鏡像簽名驗(yàn)證的完整邏輯沒(méi)必要再重復(fù)造輪子。而且它們支持熱更新策略規(guī)則不需要重啟APIServer。三、第二道防線鏡像掃描——在出事之前把漏洞揪出來(lái)3.1 鏡像掃描解決什么問(wèn)題鏡像簽名解決的是這個(gè)鏡像有沒(méi)有被篡改而鏡像掃描解決的是這個(gè)鏡像本身有沒(méi)有漏洞。??這是兩道完全不同的防線。簽名保證完整性掃描保證安全性。少了任何一個(gè)你的供應(yīng)鏈安全都有窟窿。3.2 主流工具Trivy vs Grype維度TrivyGrype開(kāi)發(fā)商Aqua SecurityAnchore漏洞庫(kù)自家 NVD RedHat Alpine 等14個(gè)源自家 NVD RedHat Ubuntu 等掃描速度???? 非?？??? 較快SBOM支持CycloneDX SPDXCycloneDX SPDX策略引擎內(nèi)置 Cosign 配置策略需要 Syft 配合容器鏡像層緩存??當(dāng)前不支持K8s 集成Trivy OperatorCRD 準(zhǔn)入社區(qū)方案我的推薦日常開(kāi)發(fā)用Trivy就夠了。理由很直接——Trivy Operator可以做成CRD掃描K8s集群中所有Pod的鏡像跟K8s生態(tài)綁定最緊密不用額外運(yùn)維一套掃描系統(tǒng)。3.3 實(shí)戰(zhàn)Trivy全量掃描 CI集成# 安裝 Trivy # Mac brew install trivy # Linux curl -sfL https://raw.githubusercontent.com/aquasecurity/trivy/main/contrib/install.sh | sh # 掃描單個(gè)鏡像 trivy image registry.example.com/ai-inference:v1 # 掃描并輸出JSON供后續(xù)處理 trivy image --format json --output scan-result.json \ registry.example.com/ai-inference:v1 # 只掃描 HIGH / CRITICAL 級(jí)別建議CI用這種模式 trivy image --severity HIGH,CRITICAL \ --exit-code 1 \ --ignore-unfixed \ registry.example.com/ai-inference:v1??必配參數(shù)說(shuō)明--exit-code 1發(fā)現(xiàn)漏洞時(shí)讓CI失敗阻止有問(wèn)題的鏡像進(jìn)入倉(cāng)庫(kù)--ignore-unfixed忽略沒(méi)有修復(fù)方案的漏洞很多OS包漏洞確實(shí)沒(méi)有補(bǔ)丁掃出來(lái)也沒(méi)用白白阻塞流水線--severity HIGH,CRITICAL只關(guān)心中高風(fēng)險(xiǎn)LOW/MEDIUM級(jí)別的漏洞閾值下可以放過(guò)3.4 準(zhǔn)入控制Trivy Operator 在K8s層自動(dòng)掃描Trivy Operator是精品——它作為Operator運(yùn)行在集群內(nèi)自動(dòng)發(fā)現(xiàn)并掃描所有Pod的鏡像同時(shí)提供Admission Controller準(zhǔn)入Webhook在Pod創(chuàng)建前自動(dòng)掃描# 安裝 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會(huì)自動(dòng)創(chuàng)建VulnerabilityReportCRD每個(gè)Pod都會(huì)有一個(gè)對(duì)應(yīng)的掃描報(bào)告# 查看所有漏洞報(bào)告 kubectl get vulnerabilityreports -A # 查看某個(gè)Pod的詳細(xì)漏洞 kubectl get vulnerabilityreport pod-ai-inference-xxxxx -o yaml如果再配合準(zhǔn)入Webhook所有新創(chuàng)建的Pod如果不滿足漏洞閾值直接拒絕# 準(zhǔn)入策略拒絕包含CRITICAL漏洞的鏡像 apiVersion: aquasecurity.github.io/v1alpha1 kind: ClusterConfigAuditReport ... # 這里實(shí)際上是通過(guò)Trivy Operator的ConfigMap配置策略 # 在 trivy-operator 命名空間修改配置即可 kubectl edit configmap trivy-operator -n trivy-system四、第三道防線RuntimeClass安全沙箱——用硬件隔離兜底4.1 為什么還需要沙箱前兩道防線解決的是供應(yīng)鏈安全——鏡像是否可信、是否有漏洞。但它們解決不了運(yùn)行時(shí)逃逸的問(wèn)題。只要你的容器和宿主機(jī)共享Linux內(nèi)核這是Docker和runc的默認(rèn)模式就有逃逸的可能——CVE-2022-0185Linux內(nèi)核越界漏洞、CVE-2024-21626runc文件描述符泄露……每年的逃逸漏洞輪著來(lái)。??AI容器的特殊性AI推理Pod需要掛載GPU、請(qǐng)求巨量顯存、可能掛載額外的模型存儲(chǔ)。這些特權(quán)操作天然增加了逃逸攻擊面。4.2 RuntimeClass 安全沙箱方案K8s的RuntimeClass機(jī)制就是為解決這個(gè)問(wèn)題的——讓不同的Pod跑在不同的容器運(yùn)行時(shí)上。核心思路高風(fēng)險(xiǎn)的AI推理Pod跑在輕量級(jí)VM沙箱里跟宿主機(jī)完全隔離。維度Kata ContainersgVisor隔離級(jí)別輕量級(jí)VM硬件虛擬化用戶態(tài)內(nèi)核應(yīng)用層攔截性能損耗~5-10%接近原生~15-40%系統(tǒng)調(diào)用越多越慢GPU支持? 完整支持GPU passthrough? 不支持GPU直通兼容性????? 所有系統(tǒng)調(diào)用都支持??? 部分系統(tǒng)調(diào)用不兼容啟動(dòng)速度較慢需啟動(dòng)VM很快進(jìn)程級(jí)安全等級(jí)更高硬件隔離較高軟件隔離適用場(chǎng)景AI推理、GPU負(fù)載、高風(fēng)險(xiǎn)Pod通用Web服務(wù)、低風(fēng)險(xiǎn)PodAI場(chǎng)景的明確建議AI推理Pod用Kata Containers——GPU passthrough是剛需沒(méi)有替代方案。損失5-10%的性能換的是完整的硬件隔離。Web服務(wù) / 數(shù)據(jù)處理Pod用gVisor——不需要GPU系統(tǒng)調(diào)用模式簡(jiǎn)單gVisor足夠。管理面Podkube-system下的組件用默認(rèn)runc——改運(yùn)行時(shí)可能導(dǎo)致兼容性問(wèn)題。4.3 實(shí)戰(zhàn)配置Kata Containers RuntimeClass# 1. 安裝Kata Containers選擇一個(gè)節(jié)點(diǎn)做測(cè)試 # 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. 創(chuàng)建 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. 標(biāo)記kata節(jié)點(diǎn) 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??注意事項(xiàng)啟用Kata的節(jié)點(diǎn)建議打上taint只調(diào)度安全Pod避免非安全Pod也跑到Kata節(jié)點(diǎn)上浪費(fèi)資源GPU passthrough需要節(jié)點(diǎn)支持SR-IOV或直通不是所有硬件都支持Kata對(duì)存儲(chǔ)有額外的Overhead建議用local SSD而非網(wǎng)絡(luò)存儲(chǔ)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 # 創(chuàng)建 RuntimeClass cat EOF | kubectl apply -f - apiVersion: node.k8s.io/v1 kind: RuntimeClass metadata: name: gvisor handler: runsc EOF五、第四道防線PodSecurity標(biāo)準(zhǔn)——從憑感覺(jué)到按標(biāo)準(zhǔn)5.1 PodSecurity的進(jìn)化史PodSecurity PoliciesPSP那會(huì)兒是真的反人類——一個(gè)PSP寫(xiě)200行YAML是常事而且邏輯復(fù)雜到連K8s大佬都配不對(duì)。好在K8s v1.21開(kāi)始引入PodSecurity Admissionv1.25正式GA把PSP替代了。PodSecurity標(biāo)準(zhǔn)只有三個(gè)等級(jí)但覆蓋了95%以上的容器安全配置等級(jí)說(shuō)明典型限制Privileged不受限——啥都能干沒(méi)有額外限制Baseline最小受限——防已知特權(quán)升級(jí)禁止privileged、禁止hostNetwork、禁止hostPID/IPC、限制Seccomp等Restricted強(qiáng)受限——遵循Pod安全最佳實(shí)踐Baseline基礎(chǔ)上強(qiáng)制non-root、限制capabilities、限制SELinux等實(shí)際建議你的集群中90%的Pod都應(yīng)該用Restricted只有那些實(shí)在不兼容的特殊Pod比如網(wǎng)絡(luò)插件、監(jiān)控agent才放寬到Baseline或Privileged。5.2 實(shí)戰(zhàn)Enforce Warn Audit 三模式部署PodSecurity采用三種模式而非一刀切讓你可以漸進(jìn)式落地# 命名空間級(jí)別配置 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創(chuàng)建時(shí)給警告但不會(huì)拒絕 pod-security.kubernetes.io/warn: baseline pod-security.kubernetes.io/warn-version: latest # Audit不符合的在審計(jì)日志記錄但沒(méi)有任何用戶可見(jiàn)影響 pod-security.kubernetes.io/audit: baseline pod-security.kubernetes.io/audit-version: latest --- # 集群級(jí)默認(rèn)值 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等系統(tǒng)命名空間 namespaces: [kube-system, gatekeeper-system, trivy-system] # 豁免特定運(yùn)行時(shí)類 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運(yùn)行時(shí)——第三道防線 runtimeClassName: kata-qemu securityContext: # 關(guān)鍵Pod級(jí)別的安全上下文 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??常見(jiàn)踩坑點(diǎn)readOnlyRootFilesystem: true會(huì)導(dǎo)致應(yīng)用在根目錄寫(xiě)臨時(shí)文件失敗。必須聲明emptyDir來(lái)掛載/tmp和/var/tmp等寫(xiě)目錄。runAsNonRoot: truerunAsUser: 1000必須確保鏡像內(nèi)的進(jìn)程是用1000uid跑的。如果Dockerfile里用root啟動(dòng)這里直接創(chuàng)建失敗。AI推理框架如Triton Server有自己的進(jìn)程管理邏輯要注意這些框架的安全配置兼容性。六、分層防御總覽四道防線如何協(xié)同工作下面的圖展示了AI容器從提交到運(yùn)行的完整防御鏈路flowchart TD subgraph 開(kāi)發(fā)者側(cè) A[代碼提交] -- B[CI流水線] B -- C[Trivy鏡像掃描] C -- D{漏洞達(dá)標(biāo)?} D --|否| E[阻斷-返回修復(fù)] D --|是| F[Cosign/Notation簽名] F -- G[推送鏡像到倉(cāng)庫(kù)] end subgraph K8s集群側(cè) H[創(chuàng)建Pod請(qǐng)求] -- I[Admission Webhook] I -- J[Ratify/Kyverno驗(yàn)簽] J -- K{簽名有效?} K --|否| L[拒絕Pod創(chuàng)建] K --|是| M[PodSecurity校驗(yàn)] M -- N{符合Restricted?} N --|否| O[Warn/Reject] N --|是| P[Pod調(diào)度] P -- Q{Schedule調(diào)度策略} Q --|AI推理Pod| R[RuntimeClass:kata-qemu] Q --|Web服務(wù)Pod| S[RuntimeClass:gvisor] Q --|系統(tǒng)組件| T[默認(rèn)runc] end subgraph 運(yùn)行時(shí) R -- U[Kata輕量級(jí)VM隔離] S -- V[gVisor用戶態(tài)內(nèi)核] T -- W[標(biāo)準(zhǔn)容器] U -- X{運(yùn)行時(shí)監(jiān)控} V -- X W -- X X -- Y[Falco/告警] end每一層的職責(zé)防線防御對(duì)象生命周期階段核心工具繞過(guò)成本①鏡像簽名與驗(yàn)證鏡像篡改、供應(yīng)鏈攻擊構(gòu)建→部署Cosign/Notation Ratify/Kyverno攻破私鑰/CA或繞過(guò)Admission②鏡像掃描已知漏洞、惡意依賴構(gòu)建時(shí) 運(yùn)行時(shí)持續(xù)Trivy/Grype Trivy Operator漏洞不上報(bào)或掩蓋特征③RuntimeClass沙箱容器逃逸、內(nèi)核漏洞運(yùn)行時(shí)Kata Containers / gVisor逃出VM或突破Seccomp④PodSecurity標(biāo)準(zhǔn)配置缺陷、過(guò)度特權(quán)部署準(zhǔn)入PodSecurity Admission找到豁免條件或利用不兼容點(diǎn)攻擊路徑與防御矩陣下面的Mermaid圖直觀展示了四類典型攻擊分別會(huì)被哪道防線攔截——紅色劃線表示被攔截綠色勾表示可繞過(guò)需要更上游防線兜底flowchart LR subgraph 攻擊向量 A1[惡意鏡像投毒] A2[供應(yīng)鏈依賴篡改] A3[內(nèi)核漏洞逃逸] A4[容器過(guò)度特權(quán)] end subgraph 防線攔截 L1[①鏡像簽名驗(yàn)證] L2[②漏洞掃描] L3[③RuntimeClass沙箱] L4[④PodSecurity標(biāo)準(zhǔn)] end subgraph 攔截結(jié)果 R1[? 攔截 - 簽名不匹配] R2[? 攔截 - CVE超閾值] R3[? 攔截 - VM隔離] R4[? 攔截 - Restricted策略] R5[?? 需要⑤運(yùn)行時(shí)監(jiān)控兜底] end A1 --|鏡像digest不一致| L1 L1 --|驗(yàn)簽失敗| R1 A2 --|依賴含已知漏洞| L2 L2 --|CRITICAL漏洞| R2 A3 --|利用內(nèi)核syscall| L3 L3 --|Kata硬件虛擬機(jī)| R3 A3 -.-|突破沙箱| R5 A4 --|特權(quán)操作被限制| L4 L4 --|非root只讀FS| R4攻擊類型繞過(guò)第一道繞過(guò)第二道繞過(guò)第三道繞過(guò)第四道惡意鏡像投毒? 簽名驗(yàn)證? 漏洞掃描? 無(wú)法阻止? 無(wú)法阻止供應(yīng)鏈依賴篡改? 簽名驗(yàn)證? 漏洞掃描? 無(wú)法阻止? 無(wú)法阻止內(nèi)核漏洞逃逸? 簽名有效即可? 能過(guò)掃描? Kata VM隔離? 非內(nèi)核級(jí)問(wèn)題容器過(guò)度特權(quán)? 簽名有效即可? 能過(guò)掃描? 縮小攻擊面? Restricted策略宿主文件訪問(wèn)? 簽名有效即可? 能過(guò)掃描? Kata文件系統(tǒng)隔離? 只讀根文件系統(tǒng)網(wǎng)絡(luò)橫向移動(dòng)? 簽名有效即可? 能過(guò)掃描? 沙箱內(nèi)仍可網(wǎng)絡(luò)通信? 無(wú)直接防御七、生產(chǎn)級(jí)完整YAML清單下面是一份可以直接用于生產(chǎn)環(huán)境的完整配置組合# 文件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命名空間級(jí)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鏡像簽名驗(yàn)證策略 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生產(chǎn)級(jí)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: # 顯式聲明容器運(yùn)行時(shí) 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 不要一上來(lái)就全量推行我見(jiàn)過(guò)太多團(tuán)隊(duì)“我們?cè)谒忻臻g強(qiáng)制enforce: restricted” 然后……所有人都被阻塞了然后……策略被回滾了。建議的落地節(jié)奏第1周所有命名空間用audit模式觀察哪些Pod不滿足第2周對(duì)不滿足的Pod逐個(gè)評(píng)估要么改代碼適應(yīng)Restricted要么確認(rèn)豁免第3周核心業(yè)務(wù)命名空間切到enforce: restricted第4周全量切enforce: restricted保留warn: baseline作為新風(fēng)向標(biāo)8.2 關(guān)于性能損耗??不要無(wú)腦對(duì)所有Pod啟用Kata Containers。Kata的VM啟動(dòng)開(kāi)銷在5-20秒之間對(duì)于水平擴(kuò)展頻繁匹配Pod的應(yīng)用這個(gè)延遲是不可接受的。而且不是所有CPU都支持Kata需要的虛擬化擴(kuò)展Intel VT-x/AMD-V。合理策略高風(fēng)險(xiǎn)AI推理Pod → Kata安全 性能批處理/離線任務(wù) → Kata可接受額外啟動(dòng)時(shí)間在線Web服務(wù) → gVisor啟動(dòng)快隔離夠用kube-system組件 → runc不改運(yùn)行時(shí)8.3 別忘了運(yùn)行時(shí)監(jiān)控四道防線都配好了但你以為就完事了運(yùn)行時(shí)監(jiān)控是第五道防線可選增強(qiáng)# Falco 運(yùn)行時(shí)安全作為補(bǔ)充監(jiān)控 helm repo add falcosecurity https://falcosecurity.github.io/charts helm install falco falcosecurity/falco \ --namespace falco \ --create-namespace \ --set falco.driver.kindebpfFalco可以檢測(cè)容器內(nèi)執(zhí)行shell、讀取敏感文件、創(chuàng)建網(wǎng)絡(luò)連接等等——即使攻擊者突破了Kata沙箱Falco還能在宿主機(jī)層給你報(bào)警。九、總結(jié)AI容器安全不是選一個(gè)工具就能解決的。四道防線缺一不可鏡像簽名Cosign/Notation→ 解決鏡像被篡改的問(wèn)題鏡像掃描Trivy/Grype→ 解決鏡像有漏洞的問(wèn)題RuntimeClass沙箱Kata/gVisor→ 解決逃逸攻擊的問(wèn)題PodSecurity標(biāo)準(zhǔn)Restricted/Baseline→ 解決配置缺陷的問(wèn)題配置從來(lái)不是為了阻止絕對(duì)不會(huì)出事——而是為了提高攻擊成本讓攻擊者覺(jué)得不值得攻破你。今天花半天配好這四道防線明天省下的可能是一個(gè)七位數(shù)的安全事件。 推薦閱讀Cosign 官方文檔Trivy Operator 項(xiàng)目Kata Containers 架構(gòu)說(shuō)明K8s PodSecurity 標(biāo)準(zhǔn)如果你也在做AI容器安全歡迎留言交流 你覺(jué)得哪道防線最難落地標(biāo)簽容器安全鏡像簽名RuntimeClassPodSecurityKata ContainersCosignTrivy