--auto 模式不读自定义 YAML 是因为它自动探测节点角色后硬编码加载内置 cfg/master.yaml 或 cfg/node.yaml，完全忽略 --benchmark 和 --config-dir 参数；想用自定义 YAML 必须关闭 --auto 并显式指定 --benchmark 路径。
为什么 --auto 模式不读你放的自定义 YAML
kube-bench 的 --auto 模式本质是自动探测当前节点角色（master 或 node），然后硬编码加载对应内置 benchmark 文件，比如 cfg/master.yaml。它完全跳过 --benchmark 或 --config-dir 参数，也不扫描你本地的 YAML 文件。
常见错误现象：kube-bench --benchmark my-custom.yaml --auto 运行结果和没加 --benchmark 一样；或者把自定义 YAML 放进 --config-dir 后仍被忽略。
-
--auto和--benchmark/--config-dir是互斥的，后者在前者开启时直接失效 - 想用自定义 YAML，必须显式指定
--benchmark，且不能带--auto - 内置 benchmark 路径固定为
cfg/下的master.yaml、node.yaml等，不会从当前目录或任意路径加载
如何让自定义 benchmark YAML 生效（不靠 --auto）
核心逻辑：关闭自动探测，手动指定配置路径。只要 --benchmark 指向一个合法 YAML，kube-bench 就会加载它并按其中定义的 controls 执行检查。
使用场景：你想增加一条检查容器运行时是否启用 seccomp，或跳过某条已知不适用的 CIS 规则。
- YAML 必须包含顶层字段
controls，每个 control 需有id、text、test_items等基本结构 - 文件路径支持相对路径，例如
--benchmark ./my-node-checks.yaml - 如果 YAML 中引用了
tests下的命令，注意cmd字段里用的 shell 命令需在目标节点环境存在（如kubectl、crictl） - 建议先用
--no-remediation测试输出，确认 control 被识别且 test_item 返回预期结果
自定义 YAML 里改 test_items 的 cmd 容易踩的坑
test_items.cmd 看似只是写个 shell 命令，但实际执行时受 kube-bench 的运行上下文严格约束：它默认以非 root 用户启动，且不加载用户 shell 配置（.bashrc、$PATH 可能不完整）。
典型错误现象：本地测试 crictl ps 成功，放到 YAML 里却报 command not found；或 kubectl get nodes 因权限不足失败。
- 所有命令必须用绝对路径，例如
/usr/bin/crictl而非crictl - 避免依赖环境变量，
cmd中不要写$HOME或未导出的变量 - 若需 kubectl 权限，确保
kube-bench进程能读取~/.kube/config，或显式用--kubeconfig参数传入 - 返回值判断只看 exit code：0 为通过，非 0 为失败；stdout/stderr 不参与判定，仅用于日志输出
扩展 benchmark 时要不要动 cfg/ 目录里的内置文件
不建议直接修改 cfg/ 下的内置 YAML。这些文件随 kube-bench 版本更新而覆盖，你的修改会被清空，且难以做版本比对和协作复用。
更稳妥的做法是维护独立 YAML，并通过 --benchmark 显式加载。如果确实需要长期复用多个扩展项，可考虑：
- 把自定义 YAML 放进 Git 仓库，CI/CD 中统一拉取
- 用
include字段（v0.6.0+ 支持）引用其他 YAML 片段，但注意嵌套层级不能太深 - 若要兼容多版本 Kubernetes，注意内置 benchmark 中
version字段与你集群的匹配性，自定义 YAML 可省略该字段，由--version参数统一控制
真正麻烦的是 test_item 的稳定性——CIS 规则本身会变，Kubernetes 组件输出格式也会变，一条写死的 grep -q 'seccomp' 很可能在下个小版本就失效。得盯着上游变更，而不是只管 YAML 文件有没有被加载。
