Kubernetes安全扫描实战：从镜像到准入控制-代码聚汇网

做了快十年运维，从裸机时代一路干到Kubernetes大规模落地，这几年被问得最多的问题不是"怎么把服务跑起来"，而是"集群起来了，安全怎么办"。说句实在话，很多团队的K8s集群能用，但经不起一次认真的安全扫描——不是没有工具，而是不知道要扫什么、什么时候扫、扫完怎么处置。这篇文章我就把这几年做Kubernetes安全扫描的完整思路、底层原理和踩坑记录整理出来，讲的都是我在生产环境里实际验证过的东西。

先交代一下背景。我目前管理着十几套Kubernetes集群，从开发测试到生产环境都有，工作职责就是保证这些集群上的业务稳定运行，其中包括镜像安全、集群配置基线、运行时异常检测、供应链安全这几条线。这篇文章适合运维工程师、平台工程师和刚接手K8s安全治理的同学，文章不会只推荐工具，更重要的是把K8s安全扫描的完整链路讲清楚：从Kubernetes如何调用containerd、镜像层结构到底长什么样，到准入控制器怎么拦截不安全的Pod、漏洞报告出来之后怎么排优先级，一条线走到底。

1. 安全边界早就变了：K8s安全扫描到底在扫什么

先说一个最基础的认知问题：Kubernetes安全扫描和传统的主机漏洞扫描完全是两码事。很多人一开始拿着传统思路来做，装了漏洞扫描器扫了一轮宿主机，报告出来说"系统很干净"，实际上集群里的问题一个都没发现。原因很简单：K8s引入了太多传统运维里不存在的东西——镜像、Pod、Service、Ingress、RBAC、准入控制、容器运行时。这些全都需要单独的安全扫描维度，而且任何一个环节有洞，都可能导致整个集群被横向渗透。

1.1 传统主机扫描的思路为什么在K8s里失效

传统场景下，操作系统是相对固定的，你扫描一台物理机或虚拟机，扫的是内核版本、系统库、开放端口、弱口令这类静态资产。但K8s的节点是"弹性"的：节点可以被自动替换，Pod可以在不同节点之间调度，镜像可以随时更新。更关键的是，你的真正业务代码是跑在Pod里的，而Pod里的进程依赖的是镜像里的基础库和二进制文件。

这意味着什么？意味着安全扫描的"对象"变了。以前扫的是"这台机器"，现在要扫的是"这个镜像"和"这个集群的配置状态"。镜像一旦构建好就不可变，但它里面包含的底层库、系统组件、中间件版本有没有已知漏洞，必须通过镜像扫描来识别。集群的配置状态更是如此，一个Privileged: true的容器、一个绑定了cluster-admin的ServiceAccount，都是配置层面的安全风险，传统主机扫描根本看不出来。

还有一点：容器运行时的引入让"进程隔离"变成了"namespace隔离+CGroup限制"的组合，这种隔离不是万能的。内核漏洞一旦被利用，容器逃逸就可能发生，所以运行时行为监控也成了安全扫描的重要组成。

1.2 四条扫描线：镜像、配置、运行时、供应链

做K8s安全扫描，落到实操我不建议直接上手买各种全家桶，先把扫描对象拆成四条清晰的线。

镜像安全扫描：扫描镜像里的操作系统软件包、应用程序依赖库、二进制模块，比对CVE漏洞库。典型工具是Trivy、Anchore、Clair。这条线的目的是解决"容器里装了一个有已知漏洞的依赖库"的问题。
集群配置安全扫描：检查Kubernetes集群本身的配置是否符合CIS Kubernetes Benchmark等安全基线的要求，包括kube-apiserver的启动参数、etcd的访问控制、RBAC权限配置、kubelet配置等。典型工具是kube-bench、kube-hunter。
运行时安全监控/扫描：对运行中的容器进程进行行为监控，检测异常系统调用、恶意文件访问、反弹Shell、容器逃逸尝试等。典型工具是Falco、Sysdig、Tetragon。
软件供应链扫描：除了最终运行的镜像，还需要扫描CI/CD流水线里用到的依赖源、Helm Chart、Git仓库中的敏感信息、基础镜像的更新策略等。典型工具是Trivy（支持对IaC、Chart、Git仓库扫描）、Snyk、Dependency-Track。

这四条线没有哪一条可以被忽略。很多团队只上了Trivy镜像扫描就觉得安全了，结果集群被入侵后一查，Falco没装，配置基线一堆红色告警——等于在漏洞上面叠漏洞。

1.3 扫描时机比工具本身更重要

工具选得再好，扫描时机不对也白搭。做镜像扫描就绕不开一个关键问题：在哪个阶段扫？

我自己实践下来，安全扫描至少要覆盖三个时机：

构建阶段（Build Time）：镜像构建完成后、push到registry之前，在CI流水线里跑一次扫描。不满足安全门槛就直接fail掉流水线，这是第一道闸门。
部署阶段（Deploy Time）：Kubernetes在创建Pod之前，通过准入控制器（Admission Controller）拦截API请求，检查镜像是否在允许列表里、是否通过了扫描、是否带有高危标签。这一步直接决定了"不安全的镜像能不能跑起来"。
运行阶段（Run Time）：集群中持续运行扫描器，周期性扫描已经部署的镜像和集群配置，并监控运行时行为。因为镜像可能在流水线扫描之后又被更新、或者旧的漏洞库过时了，运行时的持续扫描能兜底。

这三个时机缺一不可。只有构建阶段扫描，部署时可以绕过；只有运行阶段扫描，那之前的不安全部署已经造成了实际风险。串联起来，才算真正把"安全扫描"做成了"安全运营"。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. 镜像扫描的底层链路：从kubelet调用containerd说起

很多运维同学对镜像扫描工具的使用很熟练，但一旦涉及到"扫描器到底怎么拿到镜像内容"这种底层问题就说不清了。而这个问题恰恰影响你对扫描结果的理解：为什么有时候Trivy报出来的漏洞和镜像里实际跑的依赖对不上？为什么有些镜像层扫不到？这都要从Kubernetes调用容器运行时的原理说起。刚好最近热搜上也有"Kubernetes是如何调用containerd的"，这个原理不仅对理解K8s架构重要，对理解安全扫描的底层机制也一样重要。

2.1 kubelet、CRI、containerd、runc之间的协作机制

一条最核心的调用链先记下来：kubelet -> CRI -> containerd -> shim -> runc -> 容器进程。

Kubernetes的kubelet作为节点上的代理，负责管理本节点的Pod生命周期。当需要创建容器时，kubelet并不是直接去调用containerd的命令行工具，而是通过**CRI（Container Runtime Interface）**这个标准接口。CRI是Kubernetes定义的一组gRPC接口，包含RuntimeService（负责容器生命周期）和ImageService（负责镜像管理），任何容器运行时只要实现了这组接口（如containerd、CRI-O），就能被Kubernetes使用。

containerd收到CRI请求之后，会根据配置引导一个shim进程。shim是containerd和低级运行时（runc）之间的桥梁，它允许容器进程脱离containerd守护进程独立运行——这样即使containerd升级或重启，已经运行的容器也不会死掉。然后runc基于OCI标准创建容器，利用Linux内核的namespace和CGroup做隔离和资源限制。

这条链路对安全扫描的直接意义是什么？因为kubelet需要先拉取镜像、在本地"解包"镜像才能创建容器，容器运行时里天然留存了镜像的内容存储（content store）和快照（snapshot），扫描器可以从运行时层直接读取镜像文件。</ 这也是为什么很多扫描器可以做成"节点级Agent"——它们不需要拉一遍仓库里的镜像，而是直接扫描节点上已经存在的镜像内容。

2.2 扫描器眼中的镜像：OCI镜像层的结构

要把扫描器的工作原理讲透，先得知道容器的镜像在磁盘上长什么样。按照OCI Image Spec，镜像由"若干层（layer）"叠加而成，每一层其实就是一个文件系统的diff。比如一个典型镜像：

第一层：ubuntu:22.04基础操作系统文件系统
第二层：安装python3时新增的文件
第三层：安装curl时覆盖和新增的文件

每一层都可以通过一个digest（sha256哈希）唯一标识，而元数据部分存放在一个叫manifest的JSON文件里，manifest描述了层列表、配置信息、环境变量、入口命令等，manifest本身同样有digest。此外还有一个index（也叫image index），支持多架构镜像，指向不同平台对应的manifest。

扫描器读取镜像的方式有两大类：

远程扫描方式：直接调用镜像仓库的API（比如Harbor、Docker Hub、AWS ECR）拉取manifest和layers，在扫描器服务端解压并解析。优点是无需在每个节点上安装Agent，适合集中式扫描仓库镜像。
节点级扫描方式：直接读取节点上containerd的content store和snapshot数据。因为kubelet把镜像拉取到节点上后，containerd把它存在本地，扫描器Agent可以复用这部分数据。优点是扫描速度快、不需要消耗节点带宽拉取镜像，而且能扫到"节点上实际存在的所有版本"（包括被标记为Delete但还没被GC的镜像层）。

2.3 一个镜像扫描的完整数据流

以Trivy为例，把一次镜像扫描的完整数据流拆开看：

code复制镜像(nginx:1.25)
   -> Trivy拉取/读取镜像manifest
   -> 解析layer列表
   -> 解压每一层
   -> 提取各层中的包管理器数据库（dpkg status、rpm db、apk index等）
   -> 解析应用依赖清单（package-lock.json、go.sum、requirements.txt等）
   -> 生成SBOM（软件物料清单）
   -> 与漏洞数据库（NVD、GHSA、RedHat CVE等）比对
   -> 输出漏洞报告（按severity、package、affected version、fixed version排列）

这里有个容易被忽略的点：Trivy这类扫描器非常依赖"包管理器数据库"。如果镜像里删掉了/var/lib/dpkg/status这类文件，或者使用了多阶段构建把包管理器删除只留运行时文件，扫描器能够识别到的组件就会变少，漏报风险随之上升。所以多阶段构建虽然能减小镜像体积，但也让漏洞扫描的"可见面"变小了。这是镜像瘦身和安全扫描之间一个天然的矛盾。

另外，很多人以为扫描器会去扫描"层里已经不存在但历史层中存在"的漏洞。实际上扫描器是对整个解压后的rootfs做扫描，所有文件系统里可见的包都会被识别。但因为层是有序叠加的，如果后续层删除了某个有漏洞的文件，那最终rootfs里看不到它，扫描器也不会报。这是合理的——最终运行时不加载那个文件，漏洞不可达。

2.4 为什么SBOM是镜像扫描的中间产物

SBOM（Software Bill of Materials，软件物料清单）近年越来越被业界重视，甚至在物流领域都有类似的概念——就好比你在网上买了一个组装家具，快递箱里附带一张"零件清单"，列明每个零件的来源、规格和版本。SBOM对于容器镜像来说就是那份"零件清单"：它明确列出了镜像中每一个组件、版本、许可证来源、以及组件之间的依赖关系。

在安全扫描的语境下，SBOM的价值体现在三个层面：

可重复扫描：镜像本身可能会被删除，但SBOM可以独立保存。下次某个组件被爆出新CVE时，不需要重新拉镜像，直接比对该镜像对应SBOM里的组件版本就知道受不受影响。
漏洞根因定位：一个镜像报出100个漏洞时，SBOM能帮你快速分辨出哪些漏洞来自基础镜像、哪些来自应用依赖、哪些来自操作系统包。修复策略完全不同。
供应链合规：审计时需要回答"这个镜像到底用了哪些开源组件"，SBOM是最好的依据，甚至不少合规框架把"生成并提供SBOM"作为硬性要求。

Trivy在扫描时默认会生成一份SBOM，也可以单独执行trivy image --format spdx-json导出SPDX格式的SBOM。我个人强烈建议在CI流水线里把SBOM作为构建产物保存下来，归入制品库管理。这不仅是安全扫描的中间产物，更是未来几年做软件供应链治理的基础设施。

3. 把扫描结果变成“不通过就不准跑”：准入控制实战

扫描器能把漏洞找出来，但真正体现安全治理水平的，是"扫描出问题之后怎么办"。如果只是每周出一份报告发到群里，那这份报告基本等于废纸——真正有效的做法是把扫描结果接入Kubernetes的准入控制链路，让不安全的镜像"根本跑不起来"。下面这部分我直接给出我在生产环境中落地的方案。

3.1 Admission Controller拦截的是什么

Kubernetes的API Server是所有请求的唯一入口，kubectl apply、K8s内部控制器调谐、用户的请求，全部要经过API Server。而Admission Controller是API Server内部的一个中间层，它可以在对象被持久化到etcd之前拦截请求，做变更（Mutating）或校验（Validating）。

准入控制分两类：

MutatingAdmissionWebhook：可以修改请求对象的内容。比如自动给Pod注入sidecar、设置默认的安全上下文、添加资源配额标签。
ValidatingAdmissionWebhook：只能批准或拒绝请求。比如检查Pod是否使用了不被允许的镜像Tag，如果不符合要求则返回拒绝信息。

安全扫描场景里，最常用的就是ValidatingAdmissionWebhook：API Server在收到创建Pod的请求时，将请求对象发送给Webhook服务器，Webhook服务器检查Pod的镜像列表，与"安全镜像清单"或扫描结果比对，决定放行还是拒绝。

另一个常被问到的问题是"Kubernetes内置了哪些准入控制器"。像AlwaysPullImages（强制每次都拉取镜像）、SecurityContextDeny（在Pod级别拒绝特定安全上下文）、PodSecurity（强制Pod安全标准）这些都是内置的。这些内置控制器是基础，但要实现"扫描镜像漏洞"这种定制逻辑，还是需要自定义Webhook或使用Kyverno这类策略引擎。

3.2 用Trivy Operator发现集群里的漏洞

在做准入控制之前，需要先把"集群内已有镜像的安全状态"摸清楚。这里我用的工具是Trivy Operator。它本质上是一个Kubernetes Operator：部署之后，它会监听集群中创建的Pod，获取Pod使用的镜像，然后调用Trivy扫描器扫描这些镜像，把结果写成一个CRD对象——VulnerabilityReport。

安装方式很简单，用Helm即可：

bash复制helm repo add aquasecurity https://aquasecurity.github.io/helm-charts
helm repo update
helm install trivy-operator aquasecurity/trivy-operator \
  --namespace trivy-system \
  --create-namespace \
  --set="trivy.ignoreUnfixed=true" \
  --set="scanJob.timeout=5m"

部署完成后，Trivy Operator会在集群里扫描已经运行的Pod镜像，并将结果写到对应的VulnerabilityReport中。查看某个命名空间下所有工作负载的漏洞报告：

bash复制kubectl get vulnerabilityreports --all-namespaces

输出结果长这样：

code复制NAMESPACE     NAME                              REPOSITORY                TAG    SCANNER   AGE
production    deployment-nginx-6d9c7dff5d-nginx  docker.io/library/nginx   1.25   Trivy     2d

想看具体漏洞明细，直接查这个CRD对象即可：

bash复制kubectl get vulnerabilityreport -n production deployment-nginx-6d9c7dff5d-nginx -o yaml

报告里会列出CVE编号、严重级别、受影响的包名、已修复版本、以及一条修复建议链接。这套东西落地之后，集群里的安全状态就有了一个"持续更新的检查清单"，不用等审计才想起来看，平时就能看到大概。

3.3 用Kyverno做镜像漏洞门禁

Trivy Operator负责"发现"，真正做强制的活，我推荐用Kyverno。Kyverno的一大优势是入门成本低：它设计上就是面向Kubernetes原生的策略引擎，写策略走的是ClusterPolicy资源，不需要单独维护一个Webhook服务器。

下面这是一个实际生效的ClusterPolicy，目标命名空间是production，策略逻辑是：如果Pod镜像中包含高严重级别的漏洞报告，并且修复版本存在（即fixedVersion非空），则拒绝创建。这依赖Trivy Operator已经生成了VulnerabilityReport。

yaml复制apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-no-high-cve-images
spec:
  validationFailureAction: Enforce
  background: false
  rules:
    - name: block-high-cve-image
      match:
        any:
          - resources:
              kinds:
                - Pod
      preconditions:
        all:
          - key: "{{ request.operation }}"
            operator: In
            value:
              - CREATE
              - UPDATE
      validate:
        message: "镜像存在高危漏洞，拒绝部署。请修复后重新构建镜像。"
        deny:
          conditions:
            any:
              - key: "{{ images.containers.*.name }}"
                operator: AnyIn
                value: []
              # 以下条件在漏洞报告中存在High/Critical级别且有修复版本时触发
              - key: "{{ images.containers.*.name }}"
                operator: AnyIn
                value: "{{ getSliceFromVulnerabilityReport }}"

这个策略实际上写起来会根据你的VulnerabilityReport字段略有不同，上面我做了简化。更可靠的做法是写一个外部API调用，让Kyverno去调用一个内部服务，这个服务查询漏洞数据库并返回"是否放行"。这个内部服务可以用很少的代码实现：接收镜像名称和Tag，查数据库，返回允许/拒绝。

无论用Kyverno还是自定义Webhook，核心思路是一致的——在Pod创建这个时间点卡住不安全的镜像。你不需要阻止开发者构建一个具有漏洞的镜像，只需要让它在生产环境跑不起来，这种治理方式对研发配合度的要求最低。

3.4 准入控制之外的网络与隔离联动

准入控制只是部署阶段的门禁，Pod运行起来之后，网络层面的安全同样需要扫描和管控。我这边有两件事是每次都必做的：

默认拒绝所有Ingress，只按需放行：所有命名空间先不要开放Ingress，每开放一个服务必须经过评审。这样做虽然运维麻烦一点，但避免了大量"不小心暴露到公网"的内部服务。
每个命名空间强制绑定NetworkPolicy：没有NetworkPolicy的命名空间里，Pod之间默认全通。恶意Pod一旦进入集群，横向移动几乎没有阻力。所以我的标准做法是：为每个命名空间提供默认的DefaultDenyNetworkPolicy，然后按业务依赖显式放行：

yaml复制apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: your-namespace
spec:
  podSelector: {}
  policyTypes:
    - Ingress
    - Egress

这类基础配置不需要复杂的工具，kubectl apply就可以。但要注意的是，光有NetworkPolicy没有配套的CI检查，很容易在后续迭代中被删除。我们是用OPA/Gatekeeper做了一层强制策略，后面第4节会说，至少保证核心生产命名空间的NetworkPolicy不能被随意删改。

4. 集群配置和运行时：另一条必须补上的扫描线

镜像扫描解决的是"容器里装了什么"的问题，但集群本身的安全配置和容器运行时的行为监控，是很多团队最容易忽略的另外一半。你看被入侵的K8s集群复盘报告，大部分不是靠镜像漏洞进入的，而是靠配置错误（比如暴露了kubelet端口、危险的RBAC权限）或者利用运行时漏洞逃逸的。所以集群配置基线扫描和运行时监控必须单独讲一讲。

4.1 kube-bench给配置做CIS基线体检

CIS（Center for Internet Security）发布了针对Kubernetes的官方安全基线Benchmark，里面包含了200多个检查项，覆盖控制面组件（kube-apiserver、etcd、kube-scheduler、kube-controller-manager）、工作节点（kubelet、kube-proxy）、以及RBAC和Pod安全标准等维度。

kube-bench是Aqua Security开源的检查工具，它的工作原理很简单：根据CIS基线规则检查目标机器上的配置文件、启动参数、文件权限、目录权限等。例如它会检查kube-apiserver的启动参数里是否包含--authorization-mode=RBAC、是否设置了--anonymous-auth=false、etc目录的权限是否过宽等。它的执行方式也灵活，可以在宿主机直接运行二进制，也可以作为Job跑在K8s集群里。

我在主节点上运行检查：

bash复制kube-bench run --targets master --check 1.1,1.2,1.3

输出的结果里每一项都会标记为PASS、FAIL或WARN，并附带解释和修改建议。跑完检查之后，关键是别浪费这份报告。把FAIL项整理成整改工单下发给对应负责人，同时在CI/CD里把kube-bench作为周期性Job纳入巡检。我们设计了一个每周日凌晨2点自动跑kube-bench、输出报告上传到日志平台的机制，这样过一段时间就能看到整改进度。

特别注意：CIS基线不是所有项都适合生产环境，灵活度要求高的环境需要"以风险为导向"地取舍。比如--anonymous-auth=false如果导致集群内某些组件无法正常工作，就需要在团队内达成共识后豁免，而不是盲目整改到100% PASS。

4.2 Falco盯住运行时异常行为

镜像扫描和配置扫描都是"静态"维度的，运行时监控则是"动态"维度的。Falco目前是容器运行时安全监控事实上的标准之一。它从Linux内核层捕获系统调用（syscall），结合内置规则判断是否存在可疑行为：比如在容器内启动了一个shell（非预期的shell），比如某个进程尝试读取敏感文件，比如发生了到内网非预期IP的出站连接，比如特权容器挂载了宿主机目录等。

Falco的部署方式是DaemonSet，每个节点跑一个Agent。安装命令：

bash复制helm repo add falcosecurity https://falcosecurity.github.io/charts
helm repo update
helm install falco falcosecurity/falco \
  --namespace falco \
  --create-namespace \
  --set drivers.kind=modern-bpf

它的告警规则怎么写，举一个最常见的例子：检测容器内运行交互式Shell。不同基础镜像的Shell路径不同，但规则可以写成：

yaml复制- rule: Terminal shell in container
  desc: A shell was used as the entrypoint/exec inside a container
  condition: >
    spawned_process and container
    and shell_procs and proc.name != "zsh"
  output: >
    %user.name used a shell inside a container (user=%user.name container=%container.info shell=%proc.name pid=%proc.pid)
  priority: WARNING

这类规则的价值在于捕获"攻击者已经进入容器"的阶段。镜像漏洞是"弱点"，Falco发现的是"被利用的行为"。哪怕攻击者通过某个未公开漏洞进入了容器，一旦他在容器内做敏感动作，Falco就会触发告警。接入告警之后还需要配套的响应动作，比如把告警接入钉钉/邮件/事件平台，并联动自动隔离异常的Pod。

4.3 装了Dashboard之后，别让安全配置拖后腿

Kubernetes Dashboard是很多团队安装的第一批组件，原因不用多说了，可视化查看资源状态、查看日志、调试问题都方便。"Kubernetes安装Dashboard"也是最近搜索热度不低的词，但我要提醒的是：Dashboard是集群管理入口，也是攻击者最想拿下的目标。

不少团队装Dashboard时图省事，直接创建一个绑定了cluster-admin权限的ServiceAccount，然后通过NodePort或者Ingress把Dashboard暴露到公网。这样做的后果是灾难性的：只要Dashboard的登录token泄露，攻击者等于拿到了整个集群的全部权限。

我个人的安全配置习惯是这样的：

不要用NodePort直接暴露Dashboard。如果必须远程访问，走kubectl proxy或者通过跳板机打隧道，让Dashboard监听在127.0.0.1。kubectl proxy会自动处理API Server的认证，访问浏览器时会弹出登录页，选择"Token"方式输入获取到的token。
创建只读的ServiceAccount，只给业务所需的最小权限。比如给开发组的Dashboard账号只授予某个Namespace的只读权限：

yaml复制apiVersion: v1
kind: ServiceAccount
metadata:
  name: dev-readonly-dashboard
  namespace: kube-system
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: dev-readonly-role
  namespace: your-business-ns
rules:
  - apiGroups: [""]
    resources: ["pods", "pods/log", "services", "deployments"]
    verbs: ["get", "list", "watch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: dev-readonly-binding
  namespace: your-business-ns
subjects:
  - kind: ServiceAccount
    name: dev-readonly-dashboard
    namespace: kube-system
roleRef:
  kind: Role
  name: dev-readonly-role
  apiGroup: rbac.authorization.k8s.io

Dashboard自身的镜像和版本要及时更新，历史上Dashboard出现过跨站脚本、权限绕过等CVE。每次升级时都要重新检查它的API版本兼容性。

这里顺带提一句，K8s里凡是"管理面"的组件（Dashboard、ArgoCD、Istio控制面、Prometheus等），都应当纳入重点安全监控范围，它们的配置安全性和其他业务应用不是一个级别的关怀。

4.4 OPA/Gatekeeper管理集群策略扫描

前面用Kyverno做了镜像漏洞门禁，我同时还用了OPA/Gatekeeper来做策略治理。它和Kyverno有重叠，但Gatekeeper更贴近"策略即代码"的哲学：策略用Rego语言编写，以ConstraintTemplate的方式打包，最终通过Constraint资源实例化到集群里。

举个例子，很多安全事件源于Pod请求了过于宽松的安全上下文。Gatekeeper可以强制要求"所有Pod必须设置runAsNonRoot: true"：

yaml复制apiVersion: templates.gatekeeper.sh/v1
kind: ConstraintTemplate
metadata:
  name: k8srequirednonroot
spec:
  crd:
    spec:
      names:
        kind: K8sRequiredNonRoot
  targets:
    - target: admission.k8s.gatekeeper.sh
      rego: |
        package k8srequirednonroot
        violation[{"msg": msg}] {
          container := input.review.object.spec.containers[_]
          not container.securityContext.runAsNonRoot
          msg := sprintf("容器 %v 缺少 runAsNonRoot 配置", [container.name])
        }
---
apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sRequiredNonRoot
metadata:
  name: require-run-as-non-root
spec:
  match:
    kinds:
      - apiGroups: [""]
        kinds: ["Pod"]
    excludedNamespaces:
      - kube-system
      - gatekeeper-system

这里我想强调一个理解上的误区：Gatekeeper/Kyverno这类策略引擎本质上就是接入到API Server准入链路里的"策略扫描器"，它扫描的不是文件或网络，而是每个写入etcd的API对象。这种"配置扫描"比其他类型的扫描更前置——它发生在对象真正落库之前。所以我把策略引擎的评价标准定为两件事：规则覆盖面（能否覆盖到CIS中RBAC/PSP相关的要求）和规则的变更审计能力（谁在什么时候修改了策略）。OPA/Gatekeeper配合gitops（策略放Git仓库里走Pull Request评审）是最好的状态。

5. 漏洞报告拿到手，怎么排修复优先级

工具跑完、报告拿到手，更大的难题来了：报告里几千个漏洞，总不能全修吧？事实是，绝大多数漏洞对你的集群来说是"不可达"或"不可利用"的。扫描工具为了低漏报，宁可多报，这导致报告里的噪声极大。所以运营层面最重要的能力不是扫出漏洞，而是从一堆漏洞里找出真正需要处理的。这部分我分享一套以风险为导向的排优先级方法。

5.1 CVSS高分不代表马上要修

首先解释一下CVSS（Common Vulnerability Scoring System）的局限。CVSS分数是一个综合了可利用性、影响范围、攻击复杂度、是否需要用户交互等维度算出来的"标准化严重性分数"。0到10分，9.0以上通常认为是Critical。但它的核心问题是它完全不考虑你的实际部署环境。

举个真实案例。我遇到过集群里一个Node.js镜像报告了一个CVSS 9.8的漏洞——攻击者可以通过网络远程执行代码。但分析后发现这个Node.js服务只在集群内部被另一个内部服务调用，完全不暴露给外部流量，而且所在节点没有公网IP，出口流量也限制了。那这个"Critical"实际上对攻击者是个很难触达的路径，优先级应当下调。

反过来，有一个CVSS 6.5的"Moderate"漏洞，涉及一个容器内运行的sudo命令权限提升。但该容器是唯一一个可以通过Ingress从公网访问的服务，而且业务上需要允许用户上传文件到容器内。攻击者一旦通过文件上传触发应用漏洞进入容器，就能用这个sudo提升到root，然后试图逃逸。这种情况下，6.5的漏洞就比上面9.8的更紧迫。所以CVSS分数只决定严重性，不决定优先级，优先级必须结合环境。

5.2 结合EPSS、暴露面和运行状态打分

我现在的排优先级方法是一个简化的风险矩阵，包含三个维度：

漏洞可利用性（EPSS）：EPSS（Exploit Prediction Scoring System）是一个社区驱动的评分模型，预测"某个漏洞在未来30天内被利用的概率"，数值在0到1之间。EPSS大于0.5的漏洞意味着有较大被野外利用的可能，需要重点关注。这个指标能有效过滤掉大量"虽然严重但几乎没人利用"的CVE。
资产暴露面：这个容器是否可以从公网访问？是否只能从内网访问？是否只有特定Pod可以访问？对应三个等级：暴露公网（高）、内网可达（中）、仅特定服务可达（低）。
运行状态：这个工作负载是否正在运行？运行的是哪个副本数？如果已经跑在生产环境并且副本数很高，那它出问题的影响面就大。

我的打分方式做一个简表，直观方便：

漏洞	CVSS	EPSS	暴露面	运行状态	最终优先级
CVE-2023-1	9.8	0.7	公网Ingress	生产3副本	立即修复
CVE-2023-2	9.1	0.02	仅集群内	测试环境1副本	下个迭代修复
CVE-2023-3	6.5	0.5	内网	生产10副本	本周修复
CVE-2023-4	7.5	0.01	内部微服务	生产2副本	30天内修复

看似粗糙，但实际用下来效率很高。你可以把这个打分逻辑写成一个简单的内部平台，从Trivy Operator的报告、Falco告警、网络策略文件里自动拉取数据，然后为每个漏洞算出一个"处置建议"。我的切身感受是当安全报告从"几百页PDF"变成"一张按优先级排好的表"之后，研发团队配合修复的意愿会大幅提升。

5.3 多集群扫描结果统一运营

管多套集群的人应该都经历过：每个集群各有一个Trivy Operator，结果分散在不同控制台里，互不相干。要集中查看所有集群的安全状态，我的做法是用Prometheus + 自定义Exporter做一个聚合。

具体点说，Trivy Operator本身会导出一部分Prometheus指标，比如trivy_operator_vulnerabilities和trivy_operator_vulnerabilities_critical等。把这些指标接入中心的Prometheus，再配合Grafana做统一看板，就能实现"一个页面看所有集群的安全状态"。

但真正有价值的还不是看板，而是自动化的跨集群处置流程。比如一个漏洞在某套集群里被确认修复后，另外几套集群里的同一漏洞报告应该被自动关联。我们内部做了一个简单的事件管理：将Trivy Operator生成的VulnerabilityReport变化作为一个事件源，通过Argo Events触发Webhook，把高危漏洞自动提升为工单。工单的状态变更会回写到集群的注解里。这样一来，从"发现漏洞"到"修复完成"就有了一个可以追溯的记录。

5.4 用LLM把安全知识沉淀成团队Wiki

最近半年我一直在做一件事：把安全扫描产生的大量教训和处置知识沉淀成团队的知识库，让下一次遇到类似漏洞时不用重新挖一遍。这其实就是最近社区里讨论的"基于LLM的Wiki最佳实践"在安全领域的落地。

具体做法是这样的：每次处理完一个重要漏洞，我会让团队里负责的同学写一份简短的处置记录，包含漏洞描述、受影响组件、检测原理、修复方法、预防建议。然后把这些记录喂给一个大语言模型，让它定期生成汇总、建立知识点之间的关系。比如它能把"nodejs镜像里常见的Exposure"和"如何做基础镜像的升级策略"两个话题连接起来。

这里我不推荐用LLM直接替代安全人员的判断。但合理的使用方式是让LLM做好信息组织和初筛：把Trivy报告里的英文漏洞描述翻译成团队能看懂的中文摘要，提取出CVE对应的攻击路径，甚至根据历史修复模式自动建议"这个漏洞是不是和之前某个依赖升级有关"。这些工作占了安全运营里面大量的重复性劳动，用LLM做初筛之后，人工只需要检查结论和做决策。现在团队的安全复盘速度明显比之前快了，这算是我们这套体系里性价比很高的一项投入。

6. 我踩过的坑和现在的标准动作

工具和流程都讲完了，最后把这几年实际踩过的坑做一个复盘。这些坑每个都花了不少时间排查，有些甚至在线上环境造成了骚乱。下面整理其中最重要的几条，希望后来者不用再走一遍弯路。我会把对应的改进动作也一并写出来，权当是给你一份可以直接抄作业的清单。

6.1 坑一：定时扫描和部署时扫描脱节

最初我们的镜像扫描只在CI流水线里做的，也就是说镜像是"干净的"才被允许推送到生产仓库。但后来发现生产环境里还是出现了高危镜像。原因是研发团队有人在提交代码时绕过了CI——不是故意，而是本地构建后直接推送到另一个内部仓库，再由一些自动化工具部署到集群。CI扫描规则根本没覆盖到那一步，等于前门堵了，后门大开着。

改进动作：集群里必须有一个持续的扫描器，比如Trivy Operator，它不管镜像是怎么进集群的，只要Pod被创建，就扫描其镜像。这也呼应了第1节的核心观点：扫描时机永远不能只依赖单点。

6.2 坑二：只扫最终镜像，忽略Helm Chart里的镜像引用

我们有个服务的部署不是直接写image字段，而是通过Helm Chart模板化的，image写在了values.yaml里。当时只对"最终生成的Pod镜像"做了扫描，但有一次升级Chart版本时，Chart模板内部用了一个新镜像标签，而新的镜像构建还没有经过我们CI扫描链。结果升级后线上运行的是一个从未被扫描过的镜像。

改进动作：在Helm Chart发布流程里增加trivy config扫描，这个命令会检查Chart文件里的镜像引用、K8s YAML的所有安全字段，比如是否设置了privileged模式、hostNetwork等。同时加了一条铁律：任何镜像Tag变更必须走同一个审批流程，不允许在Chart模板里偷偷换Tag。

6.3 坑三：准入控制规则在集群升级后失效

有一次集群从1.24升级到1.26之后，发现Kyverno那个拒绝高危漏洞镜像的策略没有生效。排查了很久，原因是升级过程中Kyverno的Webhook配置被API Server重新注册了，但旧的ValidatingWebhookConfiguration里的failurePolicy是Ignore，加上新版本API Server对Webhook的TLS校验更严格，Webhook服务出现了证书过期但被忽略的情况。最终的结果是：所有请求都通过了校验，等于门禁完全失效。

改进动作：所有准入控制组件必须纳入监控，不仅要监控组件本身是否存活，还要周期性验证"这个Webhook是否真的会拦截非法请求"。我现在的做法是每个周期跑一个冒烟测试：发送一个明显违反策略的Pod创建请求，确认被拒绝，然后再清理掉。同时Webhook的证书要设置好自动更新，不要把failurePolicy设为Ignore，除非你有明确的原因。

6.4 现在我的最小可行安全扫描方案

啰嗦了这么多，很多人可能更想要一个"最少需要做哪些东西"的清单。根据我的实践经验，给一个可以落地的基线：

镜像扫描：Trivy部署在CI流水线，加上Trivy Operator部署在集群，覆盖构建阶段和运行阶段。
集群配置扫描：kube-bench做周期巡检，最少每周一次，主节点和工作节点都要跑。
运行时监控：Falco DaemonSet部署，默认规则集即可，告警接入企业微信/钉钉。
准入控制：Kyverno或OPA/Gatekeeper至少选一个，先做Pod安全上下文（RunAsNonRoot、不允许Privileged）和镜像Tag策略，再慢慢加复杂规则。
网络策略：核心生产命名空间必须定义默认拒绝规则，并显式开放业务端口。
集中运营看板：把Trivy Operator和kube-bench数据接入Prometheus/Grafana，每周固定时间review一次。

这套方案不依赖商业产品，全部用开源组件就能搭建。等稳定跑两三个月之后，再根据实际需要叠加商业化方案或者更细粒度的合规要求。

最后说一点个人体会。做Kubernetes安全扫描，最大的阻力往往不是技术，而是"什么时候做"的定位问题。如果安全扫描只是季度性合规任务，那它永远追不上集群变化；如果把它做成部署链路上的一环（必须通过才能上线），并且持续运营，研发和运维都会慢慢习惯这个节奏。把"扫描"变成"门禁"，把"报告"变成"工单"，把"漏洞"变成"复盘"，这套循环跑通了，K8s集群的安全才算真正落地。

Kubernetes安全扫描实战：从镜像到准入控制