Shengxu · Cloud Architecture & Devops
Shengxu · Cloud Architecture & Devops

在探讨 LLM 安全之前，你的 Kubernetes 底座及格了吗？

Shengxu included in Security  Kubernetes  DevOps
 About 700 words 3 minutes 

大模型（LLM）与 AI Agent 的爆发不仅带来了业务模式的革命，也引入了诸如提示词注入、数据投毒等全新的应用层安全挑战。当大家的目光都被这些前沿漏洞所吸引时，我们不妨先停下来，问自己一个直击灵魂的问题：在探讨这些复杂的 AI 安全之前，承载所有业务的云原生底座及格了吗？

无论是前沿的 LLM 推理服务、RAG 向量数据库，还是传统的微服务与高并发网关，绝大多数现代应用最终都严重依赖底层的 Kubernetes 容器集群。如果底层基础设施千疮百孔，攻击者根本不需要费尽心机去研究复杂的应用层漏洞，直接利用一个容器逃逸就能接管宿主机并窃取核心数据。

结合正式发布的 OWASP Top 10:2025 与 OWASP Kubernetes Top Ten，本文将为你层层拆解：为什么在今天的大规模生产场景下，传统的云安全手段正面临巨大的盲区？以及我们该如何构建一套涵盖供应链、准入控制、运行时与 GitOps 的四段式防线。

传统安全手段面临的防御盲区

在 Kubernetes 这种高动态、高密度的容器编排环境中，传统的静态边界防御（如外围防火墙）与事后审计（如节点级日志分析）已暴露出严重的覆盖盲区。为了应对现代复杂的攻击链路，基础设施必须针对以下四个核心痛点进行能力演进：

  1. 上游供应链污染与源头不可信 (对应 OWASP A03 软件供应链故障) 现代攻击手段已逐渐左移。攻击者不再一味强攻运行中的集群，而是尝试在依赖库或基础镜像中植入后门。在持续交付流程中，传统的静态扫描仅能匹配已知的 CVE 漏洞，无法识别镜像在传输或构建环节是否被隐蔽篡改。

    防线演进：单纯的传输加密已不足以自证清白。必须引入 Cosign / Sigstore 等体系，对构建产物进行密码学签名，并附加 SBOM（软件物料清单）与来源证明（Attestation），确保部署的每一份工作负载来源可溯源、过程防篡改。

  2. 资源配置违规与安全基线失效 (对应 OWASP A02 与 K8s 草案 K01) 在日常排障或紧急发布时，研发人员经常为了绕过限制，直接为容器分配 Root 权限或强行挂载宿主机的敏感目录（如 /var/run/docker.sock）。这种“合法”提权行为导致集群的安全基线被严重破坏，且依赖人工规范根本无法根治。

    防线演进：必须在 API Server 的请求入口处强制接管校验权。通过设立资源准入控制（Admission Control），系统能够在对象持久化到 etcd 之前，基于声明式的策略直接阻断一切违反安全基线的部署请求。

  3. 运行时黑盒与进程级监控缺失 (对应 OWASP K10 监控短板) 传统的节点级监控（如 CPU 负载与标准输出日志）对容器内部的微观行为完全是盲视的。当存在 0-day 漏洞利用或多态恶意软件在内存中执行越权操作时，安全团队很难在第一时间捕获异常系统调用。

    防线演进：监控探针必须下沉至 Linux 内核态。利用 eBPF 技术，安全引擎可以在不修改业务代码、不引入极高开销的前提下，获取文件读写、网络连接和进程派生的全量上下文，并在恶意行为发生时在内核路径上进行同步响应。

  4. 管理权限泛滥与环境配置漂移 (对应 OWASP K8s 草案 K04) 当多名工程师或多套 CI/CD 工具同时拥有集群管理员权限时，生产环境的配置管理将陷入混乱，极易引发不可审计的策略漂移与环境不一致。

    防线演进：收敛控制面的访问权限，全面引入 GitOps 工作流。将所有的安全策略与部署配置固化为代码并托管在 Git 仓库中。任何偏离 Git 声明状态的集群内修改，都会被协调器自动覆盖或告警。

四段式防线的落地路线与组件选型

要解决上述问题，我们必须将防御手段内嵌到容器的整个生命周期中。下面我们以目前社区最成熟的开源组件为例，梳理这套四段式防线在生产环境中该怎么拼装。

1. 供应链的加密验证：Cosign 联合拦截

这是所有工作负载进入集群前必须通过的源头校验。在 CI 阶段，当镜像构建完成后，调用 Sigstore Cosign 为镜像生成签名。在集群 Admission 阶段，准入控制器（如 Kyverno 的 verifyImages 规则）会拉取公钥验证签名。未签名镜像将被拒绝创建。

2. 准入与网络的分治：Admission 拦截与微隔离

  • 资源准入控制：利用 Kyverno、OPA Gatekeeper 或 K8s 1.30 GA 的 ValidatingAdmissionPolicy。这是在 API 内部、基于 CEL（Common Expression Language）的校验能力，追求极致性能。
  • 数据面网络策略：依靠 Cilium 等现代 CNI，实施默认拒绝（deny-by-default）的东西向流量管控，基于身份（Identity）而非 IP 进行授权。

3. eBPF 运行时监控：Falco 与 Tetragon 的双层防护

  • Falco：K8s 运行时安全的“金标准”，擅长广泛的场景化告警（如反常 Shell 活动）。
  • Cilium Tetragon：专注于深度上下文关联与内核级阻断。当触发恶意行为时，Tetragon 可以在内核态直接向进程发送 SIGKILL。

4. GitOps 充当期望状态引擎

将 Argo CD 或 Flux 作为唯一协调器。注意： 必须配套严格的 RBAC 权限回收 与 Break-glass（破窗）机制，确保在紧急故障时有审计可查的特权干预手段。

架构流转与配置示意 

graph TD
    subgraph 1. CI 供应链流水线
        A[应用代码/模型文件] -->|构建阶段| B(Docker 镜像)
        B -->|Trivy扫描与 Cosign 签名| C[(安全镜像仓库)]
    end
    
    subgraph 2. GitOps 策略即代码
        D[Git 仓库: YAML 安全基线] -->|ArgoCD 持续同步| E[K8s API Server]
    end
    
    subgraph 3. K8s 集群防御纵深
        E -->|ValidatingAdmissionWebhook| F{Kyverno / OPA 准入控制}
        F -.->|校验镜像签名与 attestation| C
        F -->|校验失败: 无签名/违规| H[拒绝资源创建]
        F -->|校验通过| G[Pod 成功调度]
        
        G -->|声明式网络隔离| I[Cilium 身份感知网络]
        G -->|内核级异常检测| J[Falco / Tetragon 探针]
        
        J -->|命中高危规则| K[实时告警 / 内核态阻断]
    end
graph TD
    subgraph 1. CI 供应链流水线
        A[应用代码/模型文件] -->|构建阶段| B(Docker 镜像)
        B -->|Trivy扫描与 Cosign 签名| C[(安全镜像仓库)]
    end
    
    subgraph 2. GitOps 策略即代码
        D[Git 仓库: YAML 安全基线] -->|ArgoCD 持续同步| E[K8s API Server]
    end
    
    subgraph 3. K8s 集群防御纵深
        E -->|ValidatingAdmissionWebhook| F{Kyverno / OPA 准入控制}
        F -.->|校验镜像签名与 attestation| C
        F -->|校验失败: 无签名/违规| H[拒绝资源创建]
        F -->|校验通过| G[Pod 成功调度]
        
        G -->|声明式网络隔离| I[Cilium 身份感知网络]
        G -->|内核级异常检测| J[Falco / Tetragon 探针]
        
        J -->|命中高危规则| K[实时告警 / 内核态阻断]
    end
graph TD
    subgraph 1. CI 供应链流水线
        A[应用代码/模型文件] -->|构建阶段| B(Docker 镜像)
        B -->|Trivy扫描与 Cosign 签名| C[(安全镜像仓库)]
    end
    
    subgraph 2. GitOps 策略即代码
        D[Git 仓库: YAML 安全基线] -->|ArgoCD 持续同步| E[K8s API Server]
    end
    
    subgraph 3. K8s 集群防御纵深
        E -->|ValidatingAdmissionWebhook| F{Kyverno / OPA 准入控制}
        F -.->|校验镜像签名与 attestation| C
        F -->|校验失败: 无签名/违规| H[拒绝资源创建]
        F -->|校验通过| G[Pod 成功调度]
        
        G -->|声明式网络隔离| I[Cilium 身份感知网络]
        G -->|内核级异常检测| J[Falco / Tetragon 探针]
        
        J -->|命中高危规则| K[实时告警 / 内核态阻断]
    end

策略代码示意

准入控制：OPA Gatekeeper 拦截特权容器

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

apiVersion: templates.gatekeeper.sh/v1
kind: ConstraintTemplate
metadata:
  name: k8spsp-privileged-container
spec:
  crd:
    spec:
      names:
        kind: K8sPSP-PrivilegedContainer
  targets:
    - target: admission.k8s.gatekeeper.sh
      rego: |
        package k8spsp.privilegedcontainer
        violation[{"msg": msg}] {
          c := input.review.object.spec.containers[_]
          c.securityContext.privileged
          msg := sprintf("Privileged container is not allowed: %v", [c.name])
        }

准入控制：利用 Webhook 拦截严重漏洞

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingWebhookConfiguration
metadata:
  name: trivy-webhook
webhooks:
  - name: trivy-webhook.trivy-system.svc
    clientConfig:
      service:
        name: trivy-webhook
        namespace: trivy-system
        path: /validate
      # ⚠️ 工程建议: 生产环境下通常由 cert-manager 自动注入 caBundle
      caBundle: <BASE64_CA_BUNDLE>
    rules:
      - operations: ["CREATE", "UPDATE"]
        apiGroups: [""]
        apiVersions: ["v1"]
        resources: ["pods"]
    failurePolicy: Fail
    sideEffects: None
    admissionReviewVersions: ["v1"]

运行时防护：Tetragon 拦截敏感文件读取

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19

apiVersion: cilium.io/v1alpha1
kind: TracingPolicy
metadata:
  name: block-sensitive-files
spec:
  kprobes:
    - call: "security_file_open"
      syscall: false
      args:
        - index: 0
          type: "file"
      selectors:
        - matchArgs:
            - index: 0
              operator: "Equal"
              values:
                - "/etc/shadow"
          matchActions:
            - action: Sigkill

总结与展望

将供应链签名、Admission 准入、eBPF 监控与 GitOps 交付相结合，并非宣告 Kubernetes 集群从此“刀枪不入”——这套防线依然难以完全抵御高阶的内核 0-day 漏洞。但这一套组合拳能够显著提升攻击者的入侵成本、极大地缩短威胁检测与响应时间，并极其有效地压缩黑客在集群内横向移动的空间。

云原生安全的下一步正在探索与 AI 模型的深度融合。利用 AI 分析审计日志并自动生成最小权限的 eBPF 规则将是未来的核心趋势。

Updated on 2026-03-14 
CC BY-NC-SA 4.0
LLMDevSecOpsEBPFGitOpsOWASPAdmissionWebhook
Back | Home

Contents