适用场景
Kube-bench 安全基线扫描适用于所有 Kubernetes 集群运维与安全团队：等保或 CIS 合规审计前需要快速摸清集群安全状态、集群上线后需要定期核查配置漂移、安全评估时想用自动化手段替代人工逐项核对 kube-apiserver 参数。Kube-bench 依据 CIS Kubernetes Benchmark 对控制平面组件、etcd、工作节点与 RBAC 策略执行 200 余项检查，输出可直接落地的修复建议，是集群安全体检的标准工具。
前置条件
- 一个可访问的 Kubernetes 集群（v1.20+），建议具备 kubeconfig 管理权限（通常需要 cluster-admin 或至少对节点有访问权限）
- 在控制平面节点和工作节点上均可执行命令（可通过 SSH 或特权 Pod）
- 节点安装 Docker 或 containerd，用于以容器方式运行 Kube-bench
- 下载 Kube-bench 二进制或镜像：aquasec/kube-bench
原理说明
CIS Kubernetes Benchmark 按组件把安全配置拆分为多个检查项，每项包含适用版本、期望配置与评分（Scored/Not Scored）。Kube-bench 根据集群版本自动匹配对应基准文件（config/ 目录下的 cis-x.x 配置），通过以下方式获取实际配置：读取 kube-apiserver、kube-controller-manager、kube-scheduler、etcd 的静态 Pod 清单或 systemd 参数、检查 /etc/kubernetes 下的证书与文件权限、调用 kubelet 与 kubectl 查询运行时状态。检查结果分为 PASS、FAIL、WARN、INFO 四档，其中 FAIL 项即为需要修复的安全缺陷。
操作步骤
步骤一：安装 Kube-bench
推荐使用官方容器镜像，一条命令即可运行，无需污染节点环境：
# 在控制平面节点执行（自动检测版本与基准）
docker run --rm -it \
-v /etc/kubernetes:/etc/kubernetes:ro \
-v /var/lib/etcd:/var/lib/etcd:ro \
-v /var/run/docker.sock:/var/run/docker.sock:ro \
aquasec/kube-bench:latest run若节点使用 containerd 而非 Docker，去掉 docker.sock 挂载即可；二进制方式安装则执行：
curl -L https://github.com/aquasecurity/kube-bench/releases/download/v0.9.3/kube-bench_0.9.3_linux_amd64.tar.gz | tar xz
./kube-bench run步骤二：解析扫描结果
扫描结束后终端会按 Master / Control Plane、Worker Node、Policies（RBAC） 分区输出汇总：
== Summary ==
0 checks PASS
25 checks FAIL
9 checks WARN
0 checks INFO结果同时以 JSON 输出便于归档（加 --json 参数），建议保存到独立目录：
./kube-bench run --json > kube-bench-$(date +%F).json步骤三：修复高频 FAIL 项
绝大多数 FAIL 项集中在 kube-apiserver 参数缺失，以下为最常见的三项修复示例：
# 1) 2.1 审计日志未启用：编辑 /etc/kubernetes/manifests/kube-apiserver.yaml
- --audit-log-path=/var/log/kubernetes/audit.log
- --audit-log-maxage=30
- --audit-log-maxbackup=10
- --audit-log-maxsize=100
# 2) 1.2.1 匿名请求未禁用：检查 --anonymous-auth=false
# 3) 4.1.1 kubelet 匿名访问：编辑 /var/lib/kubelet/config.yaml
authentication:
anonymous:
enabled: false修改后 apiserver 与 kubelet 会自动重启（静态 Pod 清单变更秒级生效），重新扫描确认修复。
步骤四：纳入定期扫描
用 CronJob 实现每周自动扫描并推送结果，创建 cronjob-kube-bench.yaml：
apiVersion: batch/v1
kind: CronJob
metadata:
name: kube-bench
namespace: kube-system
spec:
schedule: "0 2 * * 1" # 每周一凌晨 2 点
jobTemplate:
spec:
template:
spec:
hostPID: true
containers:
- name: kube-bench
image: aquasec/kube-bench:latest
args: ["run", "--json"]
volumeMounts:
- name: etc-kubernetes
mountPath: /etc/kubernetes
- name: var-lib-etcd
mountPath: /var/lib/etcd
restartPolicy: Never
volumes:
- name: etc-kubernetes
hostPath:
path: /etc/kubernetes
- name: var-lib-etcd
hostPath:
path: /var/lib/etcd
kubectl apply -f cronjob-kube-bench.yaml配置验证
# 1) 验证基准版本正确匹配
./kube-bench run --version # 输出当前 K8s 版本与匹配的 CIS 基准版本
# 2) 验证审计日志生效
ls -la /var/log/kubernetes/audit.log && tail -5 /var/log/kubernetes/audit.log
# 3) 验证匿名访问已禁用
kubectl --token=xxx --server=https://127.0.0.1:6443 get nodes
# 使用错误/匿名 token 应返回 401 Unauthorized常见问题
FAQ 1：Kube-bench 扫描会不会影响集群运行？
不会。Kube-bench 只读方式获取配置（挂载均为 :ro 只读），不修改任何组件参数、不重启服务。唯一需要留意的是挂载 /var/lib/etcd 目录用于读取 etcd 数据目录配置，属于只读访问，可放心在业务集群执行。
FAQ 2：托管集群（如 EKS、ACK）扫描结果大量 FAIL 怎么办？
托管集群的控制面由云厂商管理，apiserver 参数无法修改，这类 FAIL 项应视为 无法修复项并记录为接受风险。建议在结果文件中用 –config 指定自定义基准，通过 skip 配置排除托管组件检查项，只关注可修复的节点与 RBAC 策略部分。
总结
Kube-bench 以最小成本把 CIS Kubernetes Benchmark 变成一条命令的例行体检：容器方式零安装、JSON 输出可归档、CronJob 可自动化。上线流程建议：首次扫描后优先修复 Scored 且 FAIL 的检查项（审计日志、匿名访问、RBAC 最小权限），随后每周自动扫描并与基线比对，确保集群配置漂移及时被发现。