AI容器安全不是配個(gè)NetworkPolicy就完事了——鏡像被投毒、容器被逃逸、配置有缺陷任何一個(gè)短板都能讓整個(gè)集群淪陷。目錄一、你的AI容器真的安全嗎二、第一道防線鏡像簽名與驗(yàn)證——讓假鏡像無處遁形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)簽三、第二道防線鏡像掃描——在出事之前把漏洞揪出來3.1 鏡像掃描解決什么問題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)——從憑感覺到按標(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 不要一上來就全量推行8.2 關(guān)于性能損耗8.3 別忘了運(yùn)行時(shí)監(jiān)控九、總結(jié)一、你的AI容器真的安全嗎先問一個(gè)扎心的問題你公司用的AI推理鏡像是誰打的從哪個(gè)倉庫拉的打完有沒有被人改過如果你回答不上來那恭喜你——你已經(jīng)踩進(jìn)了容器安全最致命的坑。2025年的AI工程化浪潮里幾乎每家公司都在搶著上Kubernetes跑AI負(fù)載。模型推理用Pod拉起訓(xùn)練用Job分布數(shù)據(jù)預(yù)處理用CronJob定時(shí)執(zhí)行——看起來很美好對(duì)吧但現(xiàn)實(shí)是AI容器比普通業(yè)務(wù)容器更容易成為攻擊目標(biāo)??鏡像投毒AI鏡像動(dòng)輒幾個(gè)GB到十幾GB基礎(chǔ)鏡像里塞個(gè)挖礦腳本、改個(gè)Python依賴很難被發(fā)現(xiàn)。2024年就爆出過PyPI上的torch包被投毒事件那些鏡像如果被CI/CD流水線拉下來直接推生產(chǎn)……??逃逸攻擊AI推理需要GPU直通、需要掛載大容量存儲(chǔ)權(quán)限難免放寬。一旦有攻擊者通過模型文件注入觸發(fā)容器逃逸宿主機(jī)的GPU顯存數(shù)據(jù)、模型權(quán)重文件全暴露。??配置缺陷大部分AI團(tuán)隊(duì)focus在模型精度上寫出來的K8s YAML就倆字——奔放。privileged: true、hostNetwork、hostPath——比你家大門還敞亮。我見過一個(gè)真實(shí)的案例某AI公司的推理Pod直接用root跑掛載了宿主機(jī)的docker.sock結(jié)果一個(gè)模型輸入層面的RCE就讓攻擊者拿到整個(gè)集群的控制權(quán)——代價(jià)是全公司的模型參數(shù)被勒索損失七位數(shù)。所以容器安全從來不是配一個(gè)NetworkPolicy就完事那么簡單。今天這篇咱們就聊聊AI容器安全的四道縱深防線——從鏡像供應(yīng)鏈到運(yùn)行時(shí)隔離從Pod準(zhǔn)入到策略管控每一道都是一層過濾網(wǎng)層層遞進(jìn)、環(huán)環(huán)相扣。二、第一道防線鏡像簽名與驗(yàn)證——讓假鏡像無處遁形2.1 為什么需要鏡像簽名很多人覺得“鏡像我都是從官方倉庫拉的能有什么問題”問得好那我再問一句你能保證從拉取到部署的整個(gè)鏈條上沒人動(dòng)過這個(gè)鏡像嗎Docker Hub上的鏡像是沒有天然防篡改能力的。你拉下來的鏡像是一個(gè)tar包推上去的中間經(jīng)過的鏡像倉庫是否可信鏡像Tag是否被覆蓋過CI/CD流水線的構(gòu)建機(jī)如果被攻破推送的鏡像是否被篡改鏡像簽名的本質(zhì)用私鑰對(duì)鏡像的digest簽名任何人只要有公鑰就能驗(yàn)證鏡像的完整性和來源可靠性。誰簽的名、鏡像內(nèi)容變沒變、什么時(shí)間簽的——三個(gè)問題一次性回答。2.2 主流工具對(duì)比Cosign vs Notation目前鏡像簽名領(lǐng)域兩個(gè)主流工具二選一維度CosignNotation締造者Sigstore 社區(qū)CNCF Notary 項(xiàng)目簽名載體OCI 鏡像倉庫的 Tag 或 ReferrersOCI Artifact / ReferrersKey管理支持 KeylessOIDC 免密鑰 傳統(tǒng) Key傳統(tǒng) Key 證書鏈模式認(rèn)證集成原生支持 GitHub/GitLab OIDC支持 x509 證書策略引擎Cosign Policy 內(nèi)置Ratify 獨(dú)立組件企業(yè)友好度??? Keyless 模式降低門檻???? 證書鏈適合企業(yè)CA體系社區(qū)活躍度非常高Sigstore 社區(qū)主力較高CNCF 賽道選型建議如果你在GitHub/GitLab上的CI/CD用的是OIDC認(rèn)證強(qiáng)烈建議走Cosign的Keyless模式。這東西是真的省心——連密鑰管理都省了OIDC令牌本身就是你的身份憑證。如果貴司有嚴(yán)格的PKI體系比如基于企業(yè)CA簽發(fā)的證書Notation會(huì)更適合。2.3 實(shí)戰(zhàn)Cosign Keyless 簽名 驗(yàn)簽先說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)證或通過環(huán)境變量指配CI的OIDC token # COSIGN_EXPERIMENTAL1 cosign sign ... # 完成后簽名信息作為OCI Tag或Referrers存儲(chǔ)在鏡像倉庫中驗(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定義了誰的簽名我認(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ā)的證書 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)簽光簽名沒有任何意義只有在部署時(shí)強(qiáng)制驗(yàn)證才有用。用RatifyNotation的策略執(zhí)行引擎或Kyverno做準(zhǔn)入控制核心邏輯在K8s的Admission Webhook里攔截所有Pod創(chuàng)建請(qǐng)求檢查鏡像是否有有效簽名。沒有簽名 → 直接拒絕創(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)寫Webhook因?yàn)镵yverno/ Ratify/ OPA Gatekeeper 已經(jīng)封裝了鏡像簽名驗(yàn)證的完整邏輯沒必要再重復(fù)造輪子。而且它們支持熱更新策略規(guī)則不需要重啟APIServer。三、第二道防線鏡像掃描——在出事之前把漏洞揪出來3.1 鏡像掃描解決什么問題鏡像簽名解決的是這個(gè)鏡像有沒有被篡改而鏡像掃描解決的是這個(gè)鏡像本身有沒有漏洞。??這是兩道完全不同的防線。簽名保證完整性掃描保證安全性。少了任何一個(gè)你的供應(yīng)鏈安全都有窟窿。3.2 主流工具Trivy vs Grype維度TrivyGrype開發(fā)商Aqua SecurityAnchore漏洞庫自家 NVD RedHat Alpine 等14個(gè)源自家 NVD RedHat Ubuntu 等掃描速度???? 非?？??? 較快SBOM支持CycloneDX SPDXCycloneDX SPDX策略引擎內(nèi)置 Cosign 配置策略需要 Syft 配合容器鏡像層緩存??當(dāng)前不支持K8s 集成Trivy OperatorCRD 準(zhǔn)入社區(qū)方案我的推薦日常開發(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ù)說明--exit-code 1發(fā)現(xiàn)漏洞時(shí)讓CI失敗阻止有問題的鏡像進(jìn)入倉庫--ignore-unfixed忽略沒有修復(fù)方案的漏洞很多OS包漏洞確實(shí)沒有補(bǔ)丁掃出來也沒用白白阻塞流水線--severity HIGH,CRITICAL只關(guān)心中高風(fēng)險(xiǎn)LOW/MEDIUM級(jí)別的漏洞閾值下可以放過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í)際上是通過Trivy Operator的ConfigMap配置策略 # 在 trivy-operator 命名空間修改配置即可 kubectl edit configmap trivy-operator -n trivy-system四、第三道防線RuntimeClass安全沙箱——用硬件隔離兜底4.1 為什么還需要沙箱前兩道防線解決的是供應(yīng)鏈安全——鏡像是否可信、是否有漏洞。但它們解決不了運(yùn)行時(shí)逃逸的問題。只要你的容器和宿主機(jī)共享Linux內(nèi)核這是Docker和runc的默認(rèn)模式就有逃逸的可能——CVE-2022-0185Linux內(nèi)核越界漏洞、CVE-2024-21626runc文件描述符泄露……每年的逃逸漏洞輪著來。??AI容器的特殊性AI推理Pod需要掛載GPU、請(qǐng)求巨量顯存、可能掛載額外的模型存儲(chǔ)。這些特權(quán)操作天然增加了逃逸攻擊面。4.2 RuntimeClass 安全沙箱方案K8s的RuntimeClass機(jī)制就是為解決這個(gè)問題的——讓不同的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í)更高硬件隔離較高軟件隔離適用場景AI推理、GPU負(fù)載、高風(fēng)險(xiǎn)Pod通用Web服務(wù)、低風(fēng)險(xiǎn)PodAI場景的明確建議AI推理Pod用Kata Containers——GPU passthrough是剛需沒有替代方案。損失5-10%的性能換的是完整的硬件隔離。Web服務(wù) / 數(shù)據(jù)處理Pod用gVisor——不需要GPU系統(tǒng)調(diào)用模式簡單gVisor足夠。管理面Podkube-system下的組件用默認(rèn)runc——改運(yùn)行時(shí)可能導(dǎo)致兼容性問題。4.3 實(shí)戰(zhàn)配置Kata Containers RuntimeClass# 1. 安裝Kata Containers選擇一個(gè)節(jié)點(diǎn)做測試 # 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)——從憑感覺到按標(biāo)準(zhǔn)5.1 PodSecurity的進(jìn)化史PodSecurity PoliciesPSP那會(huì)兒是真的反人類——一個(gè)PSP寫200行YAML是常事而且邏輯復(fù)雜到連K8s大佬都配不對(duì)。好在K8s v1.21開始引入PodSecurity Admissionv1.25正式GA把PSP替代了。PodSecurity標(biāo)準(zhǔn)只有三個(gè)等級(jí)但覆蓋了95%以上的容器安全配置等級(jí)說明典型限制Privileged不受限——啥都能干沒有額外限制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ì)日志記錄但沒有任何用戶可見影響 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??常見踩坑點(diǎn)readOnlyRootFilesystem: true會(huì)導(dǎo)致應(yīng)用在根目錄寫臨時(shí)文件失敗。必須聲明emptyDir來掛載/tmp和/var/tmp等寫目錄。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 開發(fā)者側(cè) A[代碼提交] -- B[CI流水線] B -- C[Trivy鏡像掃描] C -- D{漏洞達(dá)標(biāo)?} D --|否| E[阻斷-返回修復(fù)] D --|是| F[Cosign/Notation簽名] F -- G[推送鏡像到倉庫] 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ì)象生命周期階段核心工具繞過成本①鏡像簽名與驗(yàn)證鏡像篡改、供應(yīng)鏈攻擊構(gòu)建→部署Cosign/Notation Ratify/Kyverno攻破私鑰/CA或繞過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)配置缺陷、過度特權(quán)部署準(zhǔn)入PodSecurity Admission找到豁免條件或利用不兼容點(diǎn)攻擊路徑與防御矩陣下面的Mermaid圖直觀展示了四類典型攻擊分別會(huì)被哪道防線攔截——紅色劃線表示被攔截綠色勾表示可繞過需要更上游防線兜底flowchart LR subgraph 攻擊向量 A1[惡意鏡像投毒] A2[供應(yīng)鏈依賴篡改] A3[內(nèi)核漏洞逃逸] A4[容器過度特權(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攻擊類型繞過第一道繞過第二道繞過第三道繞過第四道惡意鏡像投毒? 簽名驗(yàn)證? 漏洞掃描? 無法阻止? 無法阻止供應(yīng)鏈依賴篡改? 簽名驗(yàn)證? 漏洞掃描? 無法阻止? 無法阻止內(nèi)核漏洞逃逸? 簽名有效即可? 能過掃描? Kata VM隔離? 非內(nèi)核級(jí)問題容器過度特權(quán)? 簽名有效即可? 能過掃描? 縮小攻擊面? Restricted策略宿主文件訪問? 簽名有效即可? 能過掃描? Kata文件系統(tǒng)隔離? 只讀根文件系統(tǒng)網(wǎng)絡(luò)橫向移動(dòng)? 簽名有效即可? 能過掃描? 沙箱內(nèi)仍可網(wǎng)絡(luò)通信? 無直接防御七、生產(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 不要一上來就全量推行我見過太多團(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)于性能損耗??不要無腦對(duì)所有Pod啟用Kata Containers。Kata的VM啟動(dòng)開銷在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可以檢測容器內(nèi)執(zhí)行shell、讀取敏感文件、創(chuàng)建網(wǎng)絡(luò)連接等等——即使攻擊者突破了Kata沙箱Falco還能在宿主機(jī)層給你報(bào)警。九、總結(jié)AI容器安全不是選一個(gè)工具就能解決的。四道防線缺一不可鏡像簽名Cosign/Notation→ 解決鏡像被篡改的問題鏡像掃描Trivy/Grype→ 解決鏡像有漏洞的問題RuntimeClass沙箱Kata/gVisor→ 解決逃逸攻擊的問題PodSecurity標(biāo)準(zhǔn)Restricted/Baseline→ 解決配置缺陷的問題配置從來不是為了阻止絕對(duì)不會(huì)出事——而是為了提高攻擊成本讓攻擊者覺得不值得攻破你。今天花半天配好這四道防線明天省下的可能是一個(gè)七位數(shù)的安全事件。 推薦閱讀Cosign 官方文檔Trivy Operator 項(xiàng)目Kata Containers 架構(gòu)說明K8s PodSecurity 標(biāo)準(zhǔn)如果你也在做AI容器安全歡迎留言交流 你覺得哪道防線最難落地標(biāo)簽容器安全鏡像簽名RuntimeClassPodSecurityKata ContainersCosignTrivy