如何基于 CIS Benchmark 加固 K8s 集群？

CIS Kubernetes Benchmark 不是一份简单的安全建议，而是由国际组织 CIS 发布的、可被自动化工具执行的具体配置检查集合。它针对 Kubernetes 控制平面、数据存储、工作节点以及策略配置，给出了数百条带有编号的检查项。这些检查项的默认阈值通常对应生产环境最低安全要求，因此常被银行、政务云和互联网核心业务用作集群上线前的验收基线。对于规模不大但暴露在公网的集群，先完成 Level 1 检查，再根据业务模型选做 Level 2，可以在不显著增加运维成本的情况下消除大部分已知攻击面。

一、CIS Benchmark 的检查域与等级划分

CIS Kubernetes Benchmark 按组件划分检查域，典型包括 Master Node Security Configuration、Worker Node Security Configuration、Policies 以及 Control Plane 组件等。每个检查项都有唯一编号，例如 1.2.3 表示控制平面的某个参数要求。检查项分为 Level 1 和 Level 2：Level 1 要求明确、对多数环境无副作用，适合所有集群；Level 2 通常用于高安全环境，可能会牺牲部分兼容性或性能。加固前应先明确集群需要达到的等级，否则容易误改生产参数造成业务抖动。

从实际审计经验看，高风险问题集中在 apiserver 的匿名认证、etcd 未启用证书认证、kubelet 只读端口暴露以及默认 ServiceAccount 自动挂载。这些问题不需要修改业务代码即可修复，但需要仔细核对节点启动参数和配置文件。比如 kube-apiserver 允许匿名访问时，任何能访问 API Server 端点的客户端都可以读取部分资源，属于典型的高危基线偏差。CIS 检查项会给出期望值和修复命令，这正是它比普通安全清单更适合自动化的原因。

此外，CIS Benchmark 并不仅针对集群部署本身，也关注审计日志、事件限制和 Secret 保护。许多团队只改 apiserver 参数，却忽略了 audit log 的持久化和告警，导致入侵后无法还原操作路径。因此本文会把审计策略作为控制平面加固的一部分，而不是孤立步骤。

二、使用 kube-bench 扫描并定位配置偏差

kube-bench 是 Aqua Security 开源的 CIS Kubernetes Benchmark 扫描器，能够以容器、二进制或 Kubernetes Job 方式运行。它读取节点上的配置文件、进程参数和 API 资源，然后逐项对比 CIS 编号，输出 PASS、FAIL、WARN 三种结果。扫描报告中会直接引用检查项编号，例如 1.1.1 要求确保 kube-apiserver 的 --anonymous-auth 参数为 false。根据报告定位问题比手工查阅 PDF 高效得多。

# 以容器方式扫描 master 节点
docker run --rm -v /etc:/etc -v /var:/var -v /usr:/usr \
  aquasec/kube-bench:latest master

上面命令挂载宿主机目录，使容器内的 kube-bench 能读取 kube-apiserver 的配置文件。如果集群由 kubeadm 部署，静态 Pod 文件位于 /etc/kubernetes/manifests，kube-bench 会解析这些 YAML 里的启动命令。为了只检查某一小节，可以增加 --check 参数，如 --check 1.2.3。需要注意的是，kube-bench 的版本必须与集群大版本匹配，否则可能因检查项变化产生误报。

扫描完成后，不要直接批量执行所有修复建议。应先处理 FAIL 项，再评估 WARN。很多 FAIL 项修复需要重启相应组件，apiserver、controller-manager、scheduler、etcd 都是静态 Pod，修改 /etc/kubernetes/manifests/*.yaml 后 kubelet 会自动拉起。但生产环境应逐台滚动，避免同时重启多个控制平面节点导致集群不可用。可以在测试集群先验证参数组合是否影响业务，再发布到生产节点。

如果需要持续检测，可以把 kube-bench 部署为 Kubernetes CronJob，每日执行一次并将结果输出到日志系统。例如先创建 Job YAML，再通过 kubectl logs 收集报告。这样能防止集群因后续变更重新引入不安全配置。

三、控制平面与 etcd 的关键加固参数

控制平面加固的核心是拒绝匿名访问、启用 Node 授权模式、限制准入控制器和开启审计日志。kube-apiserver 的 --anonymous-auth 必须设置为 false；--authorization-mode 应至少包含 Node,RBAC，不要保留 AlwaysAllow。同时建议启用 NodeRestriction、PodSecurity 等准入插件，限制 kubelet 只能修改与自身 Pod 关联的资源。

# kube-apiserver.yaml 片段
spec:
  containers:
  - command:
    - kube-apiserver
    - --anonymous-auth=false
    - --authorization-mode=Node,RBAC
    - --enable-admission-plugins=NodeRestriction,PodSecurity
    - --audit-log-path=/var/log/kubernetes/audit.log
    - --audit-policy-file=/etc/kubernetes/audit-policy.yaml

etcd 存储集群所有状态，包含 Secret、ConfigMap 和证书信息。CIS 检查要求 etcd 必须启用客户端证书认证，禁止使用 HTTP 明文监听。--client-cert-auth 和 --peer-client-cert-auth 都应该为 true；--listen-client-urls 不应包含 http://，而应仅保留 https:// 地址。如果 etcd 与 apiserver 部署在同一节点，至少要将 --listen-client-urls 绑定到 https://127.0.0.1:2379，避免其他 Pod 直接访问。

审计日志方面，CIS 建议配置合理的 audit policy，至少记录元数据级别的写请求和敏感资源访问。可以创建 audit-policy.yaml，对 Secrets、ConfigMaps 等资源使用 RequestResponse 级别，其余使用 Metadata。开启审计后要给日志文件设置轮转和保留周期，否则磁盘可能被写满。以 systemd 或 kubelet 管理的节点为例，可使用 logrotate 或 Kubernetes 的 audit-log-maxage 参数控制保留天数。

四、工作节点、RBAC 与网络策略落地

工作节点最常见的偏差是 kubelet 只读端口和匿名请求。默认配置下 kubelet 可能监听 10255 只读端口，并允许未认证请求获取节点信息。CIS 要求设置 readOnlyPort: 0 并启用 Webhook 认证授权。kubelet 配置通常在 /var/lib/kubelet/config.yaml，修改后需要重启 kubelet 服务。以下为关键字段示例：

# kubelet config.yaml 片段
readOnlyPort: 0
protectKernelDefaults: true
authentication:
  anonymous:
    enabled: false
  webhook:
    enabled: true
authorization:
  mode: Webhook

RBAC 方面，CIS 检查会审计 cluster-admin 绑定数量、默认 ServiceAccount 是否自动挂载令牌以及 RoleBinding 是否过度授权。生产环境应避免直接给业务 Deployment 绑定 cluster-admin，尽量按命名空间创建 Role 和 RoleBinding。默认 ServiceAccount 可通过在 ServiceAccount 资源中设置 automountServiceAccountToken: false 或者使用专门的 ServiceAccount 并禁用自动挂载。对于需要调用 API 的工作负载，应使用 TokenRequest 获得有时效的令牌，而不是长期有效的 Secret 令牌。

网络策略是 CIS 中 Policies 检查域的重要组成部分。如果没有 NetworkPolicy，任何 Pod 之间默认可以互相访问，横向移动风险极高。建议至少为敏感命名空间创建默认拒绝入口流量和出口流量的策略，再针对实际需要放行白名单。以下 YAML 定义默认拒绝后，只允许同命名空间内带 app: web 标签的 Pod 访问数据库端口。

# network-policy.yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: db-access
spec:
  podSelector:
    matchLabels:
      app: db
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: web
    ports:
    - protocol: TCP
      port: 5432

完成加固后，建议重新运行 kube-bench 并保留报告作为合规证据。同时把关键参数纳入集群配置管理系统，避免后续扩容节点或升级集群时重新引入不安全默认值。对于使用托管 Kubernetes 服务的团队，虽然无法修改控制平面参数，但可以对照 CIS Benchmark 检查 RBAC、NetworkPolicy、Pod 安全标准和审计日志配置，并结合云厂商的安全评分服务做持续巡检。

K8s集群加固CIS Benchmarkkube-bench修改时间：2026-08-21 12:51:55