kube-bench是验证CIS合规基线最高效方式，需显式指定--targets、挂载宿主机路径、--pid=host、精准匹配--benchmark版本，并用--output json输出结构化报告。
直接用 kube-bench 扫描物理主机和 Kubernetes 底层配置，是验证 CIS 合规基线最高效的方式。它不依赖集群内运行的应用，而是聚焦在操作系统、容器运行时、Kubelet、API Server 等真实文件与进程层面，天然适配“物理主机 + 编排系统”的联合检查场景。
明确扫描目标与运行模式
kube-bench 默认会自动识别当前节点角色（master/node），但物理主机环境需主动指定，避免误判：
- 在物理服务器上直接运行时，用 --targets master 或 --targets node 显式声明角色，确保加载对应组件的检测逻辑（如 kube-apiserver、etcd、kubelet）
- 若主机同时运行控制平面和工作负载（如单节点 K3s 或 kubeadm 集群），可组合使用：--targets master,node,etcd,kubelet
- 不建议依赖自动探测——尤其在非标准路径部署（如 etcd 数据目录不在 /var/lib/etcd）时，必须配合 --config-dir 指向自定义配置目录
挂载关键宿主机路径保障深度检测
物理主机上的配置文件权限、启动参数、证书路径等，必须通过挂载方式让 kube-bench 容器可读：
- Docker 运行时加挂：-v /etc:/etc:ro -v /var:/var:ro -v /lib/systemd:/lib/systemd:ro --pid=host
- Kubernetes Job/DaemonSet 中，需在 volumeMounts 和 volumes 中声明：/etc/kubernetes、/var/lib/kubelet、/var/lib/etcd、/usr/bin 等路径
- 特别注意 --pid=host：这是获取真实进程参数（如 kube-apiserver 的 --anonymous-auth 值）的必要条件，否则只能检查静态配置文件
精准匹配 CIS 版本与 Kubernetes 实际版本
合规结论是否可信，取决于基准版本与实际环境的一致性：
- 查清物理主机上运行的 Kubernetes 组件版本（如 kubelet --version），再对照官方映射表选择基准：1.25 → cis-1.7，1.26 → cis-1.8
- 执行时显式指定：--benchmark cis-1.8，禁用自动匹配，防止因 minor 版本偏差导致漏检（例如 1.26.3 被误判为 1.26.0）
- 云托管发行版（如 EKS、GKE）需改用专用配置：--benchmark eks-1.8.0 或 --benchmark gke-1.8.0，它们已剔除不适用项并补充云特有检查
结构化输出便于基线比对与归档
人工逐行看 PASS/FAIL 效率低，应输出机器可读格式用于基线校验：
- 添加 --output json 生成标准 JSON 报告，字段含 ID（如 "1.2.6"）、status（"FAIL"）、actual_value、expected_value
- 结合 --log-file report.log 保存原始日志，满足审计留痕要求
- 用 jq 提取所有 FAIL 项：jq '.controls[] | select(.status == "FAIL") | .id, .text' scan.json，快速生成整改清单
- 将每次扫描结果按日期存档，形成物理主机与编排组件的合规演进基线图谱
