Kubernetes 集群安全加固与审计：从 CIS Benchmark 到纵深防御

Kubernetes 的安全边界是你自己划的。默认集群并不安全：API 匿名访问未关、RBAC 过度授权、无审计日志、NetworkPolicy 全开放。攻击者一旦拿到一次越权 Pod，就可能横向移动到控制面。本指南对照 CIS 基准，从控制面到工作负载到审计，建立一套「看得见、锁得住、查得到」的纵深防御。

目录

• 1. 安全模型与威胁面
• 2. CIS Benchmark 与 kube-bench：先量化差距
• 3. 控制面加固：API Server / etcd / kubelet
• 4. 认证与授权：RBAC 最小权限
• 5. ServiceAccount 与工作负载身份
• 6. Pod 安全：PSS 与准入控制
• 7. 网络隔离：NetworkPolicy 与 mTLS
• 8. 审计日志与安全可观测
• 9. 加固落地与常见坑
• 10. 总结

1. 安全模型与威胁

1.1 零信任思维

Kubernetes 默认内部网络全通（任何 Pod 能访问任何 Pod），这不是安全设计而是便利设计。加固的目标是建立零信任：默认拒绝、按需放行、一切可验。

1.2 典型攻击路径

① 弱凭据/过度授权 → 拿到过高权限
② 木马镜像 / 供应链 → 在 Pod 里执行恶意命令
③ 凭据泄露的 SA token → 访问 API Server
④ 网络全通 → 横向移动到集群产物/密钥
⑤ 无审计 → 攻击不留痕、难溯源

1.3 安全加固五支柱

一句话：先认清攻击路径（越权、恶意镜像、凭据泄露、越网、无审计），加固就不是"堆功能"而是堵对应的漏洞链。

2. CIS Benchmark 与 kube-bench：先量化差距

2.1 CIS Kubernetes Benchmark

CIS（Center for Internet Security） 提供了社区公认的 K8s 加固基线，覆盖控制面、etcd、kubelet、工作负载、RBAC、配置等上百项检查。

2.2 用 kube-bench 自动扫描

kube-bench 是对照 CIS 基准的自动审计工具，快速量化你的加固差距：

# 在控制面节点运行
kubectl apply -f kube-bench.yaml   # 或直接部署扫描 Job
kube-bench \
  --targets master,node,etcd \
  --scored                     # 只输出计分项

输出以 PASS / FAIL / WARN 分组，并给出修复建议。

2.3 加固清单先行

在配置前，先建立差距清单：把 FAIL 项映射到修复动作与负责人，形成加固台账。

一句话：先量化再加固——用 kube-bench 跑一遍 CIS 基准，让"该补哪些洞"有据可依、可追踪。

3. 控制面加固：API Server / etcd / kubelet

3.1 API Server 关键配置

# 关闭匿名访问 —— 高风险
--anonymous-auth=false

# 强认证（禁止弱客户端证书）
--client-ca-file=/etc/kubernetes/pki/ca.crt

# 限制 admin 仅本机
--bind-address=0.0.0.0  # 或用专用网段

3.2 etcd 的保护

etcd 存有所有密钥与配置，是最该保护的组件：

--client-cert-auth=true          # 客户端 mTLS
--peer-client-cert-auth=true     # 节点间 mTLS
--auto-tls   # 不要开自动TLS（会生成不可信测试证书）

3.3 kubelet 加固

--anonymous-auth=false
--authorization-mode=Webhook
--protect-kernel-defaults=true
确保只监听可信端口，关闭只读端口

一句话：控制面加固 = 关匿名 + 强认证 + mTLS 保护 etcd + 收紧 kubelet——把集群的"大脑"先锁死。

4. 认证与授权：RBAC 最小权限

4.1 RBAC 原则

最小权限：每个身份只授予完成任务所需的最小权限，杜绝 cluster-admin 满天飞。

4.2 合理拆分 Role 与 ClusterRole

# 限制在单一命名空间可读 Pod
kind: Role
metadata:
  namespace: team-a
rules:
  - apiGroups: [""]
    resources: ["pods"]
    verbs: ["get", "list", "watch"]

用 RoleBinding 绑定到用户/SA，避免滥用 ClusterRole。

4.3 常见越权风险

一句话：RBAC = 把"谁能干什么"写进声明并最小化——默认拒绝 + 按需授权，别把 cluster-admin 当万能钥匙。

5. ServiceAccount 与工作负载控制

5.1 ServiceAccount 是身份

每个 Pod 自动挂载其命名空间的 SA token。若该 token 有越权，Pod 被攻破就相当于攻击者拿到越权身份。

5.2 收紧 ServiceAccount

• 避免 Pod 挂载高权限 SA（默认可能有 get/list/watch 集群范围的权限）；
• 自动挂载 可关闭：

apiVersion: v1
kind: ServiceAccount
metadata:
  name: my-sa
automountServiceAccountToken: false   # 非必要不自动挂 token

• 为每个应用建专用 SA，并只授予最小权限。

一句话：SA 是Pod 的身份证——别让每个 Pod 都揣着"万能钥匙"，建最小权限的专用 SA 并考虑不自动挂载。

6. Pod 安全：PodSecurity 与准入控制

6.1 PodSecurity 标准（PSS）

Pod 安全的三个等级：

6.2 用 PodSecurity Admission 实施

apiVersion: pod-security.admission.config.k8s.io/v1
kind: PodSecurityConfiguration
  defaults:
    enforce: baseline        # 强制基线
    warn: restricted         # 超范围的警告
  exemptions:
    namespaces: [kube-system, monitoring]  # 系统关键

或对命名空间打标签控制：

kubectl label ns prod pod-security.kubernetes.io/enforce=restricted

6.3 更深层准入（OPA/Gatekeeper）

当 PSS 不够时，用 Gatekeeper/OPA 实现自定义策略（禁止特权、强制只读根文件系统、强制固定标签等）。

一句话：Pod 安全 = PSS 分级 + PodSecurity Admission 落地 + Gatekeeper 兜自定义——让"什么 Pod 能进集群"有硬规则。

7. 网络隔离：NetworkPolicy 与 mTLS

7.1 默认网络全通是风险

默认 K8s 网络是全通的。NetworkPolicy 让你按命名空间/标签做微隔离。

7.2 网络策略基础：默认拒绝

创建一条默认拒绝入方向，再按需放行：

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-ingress
spec:
  podSelector: {}
  policyTypes: ["Ingress"]

然后精确放行业务流。这是零信任网络的开始。

7.3 服务网格与 mTLS

在节点间流转加密方面/数据面（Service Mesh 如 Istio、Linkerd）提供 mTLS，让集群内流量也加密、双向身份可验。

一句话：NetworkPolicy 把**“默认全通"改成"默认拒绝”**，mTLS/服务网格让集群内流量也加密可验——网络也是纵深的一部分。

8. 审计日志与安全可观测

8.1 开启审计日志

K8s 审计日志 记录谁在访问了哪些 API 与结果，是溯源关键：

# audit-policy.yaml
apiVersion: audit.k8s.io/v1
kind: Policy
rules:
  - level: Metadata
    resources:
      - group: ""
        resources: ["secrets"]   # 密钥访问重点
  - level: RequestResponse
    userGroups: []

8.2 审计日志的落地

• 采集：把审计日志写入安全存储（非篡改）；
• 告警：对异常访问（secret 读取、node bind、delete）做告警；
• 分析：结合 SIEM 做安全分析。

8.3 安全可观测闭环

审计日志 → 告警 → 溯源 → 策略收紧 → 再审计

一句话：审计日志是安全的"黑匣子"——不记录等于攻击无痕；启用 + 告警 + 分析让每次越权可被发现。

9. 加固落地与常见坑

9.1 加固路线

① 扫描（kube-bench/CIS）→ 量化差距
② 控制面（API/etcd/kubelet）→ 收口
③ RBAC + SA → 最小权限
④ Pod 安全（PSS/准入）→ 控工件
⑤ 网络隔离 → 默认拒绝
⑥ 审计日志 → 可溯源
⑦ 持续：扫描 + 演练 + 基线审查

9.2 常见坑

10. 总结

五支柱：控制面、权限、产物、网络、审计。

一句话记住：安全加固不是"装一次就算"，而是一套持续巩固的纵深——用 kube-bench 量化差距、锁死控制面、最小权限治理身份、管住产物准入、网络默认拒绝、审计日志全程留痕。安全没有终点，只有不断加厚的地基。