如何通过Trivy在Kubernetes集群中全面扫描所有节点系统组件的潜在漏洞？

本文共计1054个文字，预计阅读时间需要5分钟。

Trivy默认不扫描描述节点系统组件（如kubelet、containerd、内核模块），必须显式启用节点收集器并确保权限限制到位，否则+trivy+k8s+命令只会检查API和资源配置，不会触达节点文件系统。

为什么 trivy k8s 默认不查节点漏洞

Trivy 的 trivy k8s 命令默认只读取 Kubernetes API 中的资源对象（如 Pod、Deployment、ConfigMap），它本身不登录或挂载节点磁盘。节点上的操作系统包、运行时二进制（kubelet、containerd）、内核模块等属于“主机层”，需通过 NodeCollector 作业以 Pod 形式在节点上执行本地扫描。

• 不启用 --enable-node-collector 时，所有节点相关漏洞（如 CVE-2023-24538 in containerd）完全不会出现在报告中
• 即使启用了，若 ServiceAccount 缺少 node 资源的 get/list 权限，收集器会静默失败
• 扫描结果中的 OS Packages 类型漏洞，仅来自节点上 /var/lib/dpkg（Debian）或 /var/lib/rpm（RHEL）等路径，与容器镜像扫描无关

启用节点扫描必须做的三件事

要让 Trivy 真正看到节点系统组件的漏洞，得同时满足以下条件：

• 命令中加上 --enable-node-collector（注意不是 --disable-node-collector）
• 确保当前 kubectl 上下文所用的 ServiceAccount 具备 nodes 资源的 get、list、watch 权限（通常需绑定 cluster-admin 或自定义 ClusterRole）
• 节点必须允许容忍（tolerations）和挂载宿主机路径：Trivy NodeCollector 需要挂载 /proc、/sys、/var/lib/dpkg（或对应发行版路径）才能读取系统状态

典型命令示例：

trivy k8s --report summary cluster --enable-node-collector --tolerations 'key: node-role.kubernetes.io/master,operator: Exists,effect: NoSchedule' --exclude-nodes 'kubernetes.io/os=windows'

--exclude-nodes 和 --tolerations 不是可选项，而是必填项

很多用户卡在“节点没被扫描到”，实际是因为：

• 集群里有 Windows 节点，但 Trivy NodeCollector 目前不支持 Windows 主机扫描，不加 --exclude-nodes 'kubernetes.io/os=windows' 会导致 collector Pod 在 Windows 节点上启动失败并跳过整个节点池
• 控制平面节点打了 NoSchedule 污点，但 collector Job 没配对应 tolerations，结果根本调度不上控制面节点，导致 apiserver、etcd 等组件漏扫
• 使用 --include-kinds node 没用——node 是 Kubernetes API 对象，不是可扫描的“系统组件”；真正要扫的是节点 OS 层，靠的是 collector 作业，不是资源过滤

扫描结果里哪些行代表节点系统漏洞

运行成功后，报告中会出现形如以下的条目，它们才是节点系统组件的真实漏洞：

• node/worker-1: os-pkgs: libsystemd0 (245.4-4ubuntu3.22) → 表示该节点 Debian 系统上 systemd 包存在已知 CVE
• node/control-plane-0: os-pkgs: containerd.io (1.6.28-1) → 表示该节点手动安装的 containerd 二进制存在漏洞
• node/worker-2: config: kubelet (1.28.9) → 表示 kubelet 版本低于 CIS 建议的最小安全版本（非 CVE，但属加固问题）

注意：os-pkgs 类型只出现在 node/xxx 前缀行；而 image/xxx 或 pod/xxx 开头的仍是容器镜像或工作负载层面的漏洞，和节点系统无关。

节点扫描依赖宿主机路径挂载和足够权限，一旦 collector Pod 因 toleration 缺失、污点不匹配或 RBAC 不足而处于 Pending 或 CrashLoopBackOff，就等于没扫——这点很容易被忽略，且错误不会直接报在终端，得查 kubectl get jobs -n trivy-system 和对应 Pod 日志。