3. Kubernetes集群安全基线：API Server安全配置、etcd加密、RBAC最小权限原则、Pod安全策略

Kubernetes集群的安全基线是云原生安全体系的核心支柱。本章聚焦于四个关键领域：API Server 作为集群的“大门”，etcd 作为所有状态的“存储库”，RBAC 作为权限控制的“守门员”，以及 Pod Security 作为工作负载的“安全围栏”。任何一项配置的变更都可能导致严重的安全风险，因此实时监控这些基线的变更至关重要。

3.1 API Server 安全配置基线

API Server 是 Kubernetes 控制平面的前端，所有对集群的操作请求都必须经过它。其安全配置直接决定了集群的暴露面。

3.1.1 核心安全配置项

配置项	推荐值/策略	风险说明
--anonymous-auth	false	禁用匿名请求，防止未认证访问
--enable-admission-plugins	NodeRestriction, PodSecurity, AlwaysPullImages	启用准入控制器，强制安全策略
--profiling	false	关闭性能分析接口，防止信息泄露
--audit-log-path	/var/log/kubernetes/audit.log	开启审计日志，记录所有API请求
--tls-cert-file & --tls-private-key-file	使用集群CA签发的证书	确保通信加密，防止中间人攻击

3.1.2 准入控制器链的完整性

准入控制器是API Server安全策略的“执行引擎”。基线要求必须包含以下控制器，且顺序不可随意调整：

1. NamespaceLifecycle：防止在删除中的命名空间创建资源。
2. MutatingAdmissionWebhook & ValidatingAdmissionWebhook：允许外部安全策略注入。
3. PodSecurity：替代旧版 PSP，实施 Pod 安全标准。
4. NodeRestriction：限制 kubelet 的权限。

3.2 etcd 加密与访问控制

etcd 存储了集群的所有 Secrets、ConfigMaps、状态等敏感数据。如果 etcd 被攻破，整个集群将沦陷。

3.2.1 静态加密

Kubernetes 支持对 etcd 中的资源进行静态加密。基线要求启用 EncryptionConfiguration：

apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
  - resources:
      - secrets
    providers:
      - aescbc:
          keys:
            - name: key1
              secret: <base64-encoded-32-byte-key>
      - identity: {}  # 回退策略，不应作为主策略

3.2.2 传输加密与认证

• TLS 双向认证：etcd 集群成员之间、API Server 与 etcd 之间必须使用 TLS 证书进行双向认证。
• 客户端证书轮换：监控 etcd 客户端证书的过期时间，提前 30 天发出告警。
• 访问控制：etcd 的 --peer-client-cert-auth 和 --client-cert-auth 必须设置为 true。

3.3 RBAC 最小权限原则

RBAC 是 Kubernetes 权限控制的核心。基线要求遵循“最小权限”原则，并严格监控权限的变更。

3.3.1 权限模型对比

维度	推荐基线	常见违规
ClusterRole 使用	仅系统组件使用，应用应使用 Role	为普通 ServiceAccount 绑定 cluster-admin
通配符使用	禁止使用 * 在 resources 或 verbs 中	使用 resources: ["*"] 或 verbs: ["*"]
Secrets 访问	仅允许特定 ServiceAccount 通过 RoleBinding 访问	在 ClusterRole 中授予 secrets 的 get/list/watch 权限
Pod 执行权限	禁止 pods/exec 权限	授予 pods/exec 给非管理员用户

3.3.2 关键监控指标

• ClusterRoleBinding 创建/更新：特别是涉及 system:masters 组的绑定。
• RoleBinding 跨命名空间：监控 RoleBinding 是否引用了其他命名空间的 ServiceAccount。
• 权限提升：监控是否创建了包含 escalate 或 bind 权限的 Role。

3.4 Pod 安全策略（Pod Security）

Kubernetes 1.21+ 推荐使用 Pod Security Admission 替代旧版 PSP。基线要求实施 Restricted 级别的 Pod 安全标准。

3.4.1 Pod 安全标准级别

级别	策略	适用场景
Privileged	无限制	系统级组件（如 kube-proxy）
Baseline	禁止特权容器、hostNetwork、hostPID 等	大多数应用
Restricted	强制执行 Pod 安全上下文，禁止所有特权	高安全要求的生产应用

3.4.2 命名空间级别的准入控制

通过标签 pod-security.kubernetes.io/enforce 在命名空间级别实施策略：

apiVersion: v1
kind: Namespace
metadata:
  name: production
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/enforce-version: latest
    pod-security.kubernetes.io/audit: restricted

3.5 安全基线变更的实时监控架构

以下 SVG 图展示了如何通过事件驱动架构实时监控上述四个基线的变更：

3.6 基线变更的自动化修复策略

对于某些高风险变更，除了告警外，还可以实施自动化修复（Auto-Remediation）：

• API Server 配置漂移：通过 Operator 监听 API Server Pod 的启动参数，若发现 --anonymous-auth=true，自动重启 Pod 并恢复为 false。
• RBAC 权限回滚：当检测到非预期的 cluster-admin 绑定时，自动删除该 ClusterRoleBinding 并通知管理员。
• Pod Security 标签修复：如果命名空间的 enforce 标签被删除或降级，自动通过 Admission Webhook 拒绝变更并恢复标签。

3.7 本章小结