Trivy k8s 默认不扫描节点漏洞，因其仅读取API资源，不访问节点文件系统；需显式启用--enable-node-collector，并配置RBAC权限、tolerations及宿主机路径挂载，否则节点OS组件（如kubelet、containerd）漏洞完全遗漏。
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 日志。
