Kubernetes的网络层承担着Pod间通信、服务发现、南北向流量调度等核心职责，一旦配置不当，攻击者可以利用未认证端口横向移动，甚至直接访问集群控制面数据。CIS Kubernetes Benchmark提供了一套经过广泛验证的安全配置基线，而kube-bench是CNCF官方推荐的扫描工具，它能够对照基准条款逐项检查集群配置并输出结构化报告。本文重点讨论网络相关的检测项如何扫描、如何解读，以及发现问题时该怎样修复。
kube-bench的工作原理与部署方式
kube-bench本质上是一个Go编写的命令行工具，内部维护着与CIS Benchmark版本对应的检测规则文件（通常位于/etc/kube-bench/cfg目录下，以YAML格式描述）。它通过读取组件的启动参数、检查配置文件权限、验证端口监听状态等方式，逐条比对基准要求，最终输出通过、失败或警告三种状态。对于网络相关的检测，它主要关注三类信息：kube-apiserver的监听端口与认证参数、etcd的通信加密配置、以及kube-proxy与各节点组件的网络策略设置。
部署方式非常灵活，最推荐的是以Job形式直接在集群内运行，这样工具能够访问节点的文件系统（需要挂载主机目录）。一个典型的Job定义如下：
apiVersion: batch/v1
kind: Job
metadata:
name: kube-bench
spec:
template:
spec:
hostPID: true
containers:
- name: kube-bench
image: aquasec/kube-bench:latest
command: ["kube-bench", "run", "--targets", "master,node"]
volumeMounts:
- name: var-lib-etcd
mountPath: /var/lib/etcd
- name: etc-kubernetes
mountPath: /etc/kubernetes
volumes:
- name: var-lib-etcd
hostPath:
path: /var/lib/etcd
- name: etc-kubernetes
hostPath:
path: /etc/kubernetes
restartPolicy: Never
如果不方便在集群内创建Job，也可以直接下载二进制文件在节点上执行，例如kube-bench run --targets master只扫描控制面组件。需要注意，二进制方式要求本机存在对应的配置文件和kubelet进程，否则部分检测项会直接跳过。对于托管集群（如GKE、EKS、AKS），kube-bench提供了--version参数指定对应的基准版本，因为托管环境无法看到控制面的进程参数，只能检查节点侧配置。
网络相关检测项解读
CIS Benchmark中与网络直接相关的条款集中在kube-apiserver和etcd部分。首先是1.2.x系列的apiserver检测项，比如“确保不使用insecure-port参数”。老版本Kubernetes默认开放8080端口，该端口无需任何认证即可访问全部API，是极其危险的存在。kube-bench会检查apiserver启动参数中是否出现了--insecure-port，如果发现非零值或参数存在，会直接判定失败。修复方法是从manifest中删除该参数，1.20之后的版本该参数已被彻底移除，但如果集群是从旧版本升级上来的，静态Pod定义文件里可能还残留着。
其次是etcd的通信安全。检测项2.x系列要求etcd启用客户端证书认证，且客户端与peer之间通信必须走TLS。etcd存储着集群的全部状态数据，包括Secret的明文内容，如果监听在2379端口且未启用认证，任何能访问该端口的进程都能读取所有Secret。kube-bench会检查--client-cert-auth、--cert-file、--key-file、--peer-client-cert-auth等参数。典型的合规配置如下：
# /etc/kubernetes/manifests/etcd.yaml 中的启动参数 - --client-cert-auth=true - --cert-file=/etc/kubernetes/pki/etcd/server.crt - --key-file=/etc/kubernetes/pki/etcd/server.key - --peer-client-cert-auth=true - --peer-cert-file=/etc/kubernetes/pki/etcd/peer.crt - --peer-key-file=/etc/kubernetes/pki/etcd/peer.key - --trusted-ca-file=/etc/kubernetes/pki/etcd/ca.crt - --peer-trusted-ca-file=/etc/kubernetes/pki/etcd/ca.crt
再者是kubelet相关检测。kubelet的10250端口如果配置为匿名访问（--anonymous-auth=true且--authorization-mode包含AlwaysAllow），攻击者可以通过kubelet的REST接口在节点上执行任意命令。kube-bench的4.2.x系列会逐项检查这些参数。修复时建议显式设置--anonymous-auth=false，并确保webhook授权模式生效，同时开启--rotate-server-certificates让证书自动轮换，避免长期使用同一张证书带来的风险。
最后是网络策略层面。需要明确的是，kube-bench本身并不直接检测NetworkPolicy资源，它检查的是配置层面的合规性。但在实际安全评估中，网络策略审计必须作为补充手段：默认情况下Kubernetes允许所有Pod之间自由通信，只有在命名空间级别部署默认拒绝的策略，CIS要求的纵深防御才算落地。可以配合kubectl检查：
# 查看某个命名空间的网络策略 kubectl get networkpolicy -n production # 检查命名空间是否配置了默认拒绝入口策略 kubectl describe namespace production | grep -i 'default-deny'
扫描结果分析与修复流程
kube-bench的输出分为摘要和明细两部分。摘要显示各类别通过项数、失败项数、警告项数；明细则给出每个检测项的编号、描述、实际检测结果与建议措施。例如看到“[FAIL] 1.2.4 Ensure that the --kubelet-https argument is set to true”这样的条目，说明apiserver与kubelet之间可能存在明文通信风险，需要检查apiserver配置确认该参数未被显式关闭。
对于失败项的修复，建议建立分级机制。高危项（如insecure-port、etcd匿名访问、kubelet匿名认证）应当立即处理，这些属于可直接利用的漏洞；中危项（如未启用审计日志的网络事件记录）可以在变更窗口内安排；提示类警告则纳入长期优化。修复后重新运行扫描验证，最好将kube-bench接入CI/CD或定时任务，通过--json参数输出结构化结果：
kube-bench run --targets master --json --output-file /var/log/kube-bench-report.json # 用jq提取所有失败项的编号和描述 jq -r '.Controls[].Tests[].results[] | select(.status=="FAIL") | "\(.test_number) \(.test_desc)"' \ /var/log/kube-bench-report.json
还有一个常见误区需要提醒：修改控制面组件参数通常要编辑/etc/kubernetes/manifests/下的静态Pod清单，kubelet会自动感知变化并重建容器，但etcd和apiserver的重启会导致短暂的服务不可用，生产环境务必评估好维护窗口。另外，托管集群的控制面参数用户无法修改，这类检测项的结果只能作为风险评估依据，实际防护重心应放在节点加固和网络隔离上。
总结来看，kube-bench把CIS基准中分散的数百条检查自动化了，网络相关的检测项覆盖了从apiserver端口到etcd加密再到kubelet认证的关键链路。把它作为周期性巡检工具，配合网络策略审计和持续的证书管理，才能让Kubernetes的网络层真正达到可验证的安全基线水平。
kube-benchKubernetes安全CIS基准测试修改时间：2026-09-12 16:28:35