kube-bench是CIS Kubernetes基准配置比对工具，不自动修复；其审计准确性取决于节点角色识别、基准版本匹配（如--benchmark cis-1.27）、关键路径显式挂载（如/etc/kubernetes、/var/lib/kubelet）及WARN/FAIL人工验证。
kube-bench 不是“自动修复工具”，它只做配置比对；真正能落地的审计，取决于你是否在正确的节点、用正确的参数、挂载了正确的路径。
为什么 kube-bench 在 worker 节点上跑 master 检查总显示大量 WARN 或跳过？
kube-bench 在 worker 节点上跑 master 检查总显示大量 WARN 或跳过？因为 kube-bench 默认按当前节点角色自动选择检查目标：worker 节点只执行 node 检查，不会去找 /etc/kubernetes/manifests/kube-apiserver.yaml——那玩意儿根本不在 worker 上。
- 确认角色：运行
kubectl get nodes -o wide看ROLES列，再ls /etc/kubernetes/manifests/确认是否存在kube-apiserver.yaml - master 节点必须显式指定基准版本，例如
kube-bench master --benchmark cis-1.27（版本号必须和集群实际 Kubernetes 版本一致） - 不要信
--version auto：它常把 kubeadm 1.27 集群识别成 1.26，导致检查项错配、FAIL 变多
用容器运行 kube-bench 时挂载路径为什么总是错？
kube-bench 时挂载路径为什么总是错？官方镜像默认只挂 /host，但 kube-bench 实际要读 /etc/kubernetes/manifests、/var/lib/kubelet/config.yaml、/var/lib/etcd 等——这些路径不显式挂载，就全标 WARN。
- 必须手动挂载关键路径：
-v /etc/kubernetes:/etc/kubernetes:ro -v /var/lib/kubelet:/var/lib/kubelet:ro -v /var/lib/etcd:/var/lib/etcd:ro - 如果用 systemd 启动组件（如 kube-scheduler），还得加
-v /etc/systemd:/etc/systemd:ro，否则无法读取服务文件里的启动参数 - k3s 或 MicroK8s 用户注意：它们不用
/etc/kubernetes/manifests，也不拆分 control plane 进程，直接跑kube-bench master会大面积 FAIL——这不是配置问题，是架构不匹配
FAIL 和 WARN 在实际运维中怎么区分优先级？
FAIL 和 WARN 在实际运维中怎么区分优先级？FAIL 是明确违反 CIS 条款（比如 --audit-log-path 未设置），属于必须处理的高风险项；WARN 多数是信息缺失（比如没找到 etcd PID，无法验证其 --client-cert-auth=true 是否启用），不能直接忽略。
- 对每个
WARN，人工验证真实状态：比如ps aux | grep etcd看实际启动参数，再对照 CIS 第 5.1 节要求 - 某些
FAIL可接受：如 CIS 要求禁用--anonymous-auth，但你用了外部认证代理（如 Dex + OIDC），这条可标记为已知例外 - 输出 JSON 更利于跟进：
kube-bench master --json --benchmark cis-1.27 > report.json，后续可用jq '.[] | select(.type == "fail")'快速过滤
真正卡住落地的，从来不是工具会不会跑，而是你有没有在对的节点上、用对的版本、挂对的路径、再把 WARN 当 FAIL 一样去查证。k3s/MicroK8s 用户别硬套 CIS-1.27，先看它的 cfg 目录里有没有对应 benchmark 文件——没有就别强跑。
