2. 控制平面基础：控制平面定义、Kubernetes控制平面组件、控制平面安全模型
2.1 控制平面定义与核心职责
控制平面（Control Plane）是分布式系统中负责全局决策与状态协调的逻辑层。在 Kubernetes 生态中，控制平面是集群的“大脑”，它不直接运行用户业务容器，而是持续维护集群的期望状态（Desired State），并通过一系列控制循环（Control Loop）将其与实际状态（Actual State）对齐。
核心职责：
- API 网关：暴露 Kubernetes API，接收并验证所有资源操作请求。
- 调度决策：为新创建的 Pod 选择最合适的 Worker 节点。
- 状态维护：通过控制器（Controller）持续监控集群状态，执行扩缩容、故障恢复等操作。
- 数据持久化：将集群所有资源对象（Pod、Service、ConfigMap 等）存储在可靠的键值数据库中。
- 安全准入：在请求持久化之前，执行认证、授权与准入控制（Admission Control）。
2.2 Kubernetes 控制平面组件详解
Kubernetes 控制平面由多个独立组件构成，每个组件承担特定职责，并通过 API Server 进行通信。下表列出核心组件及其功能对比：
| 组件名称 | 核心功能 | 通信方式 | 高可用要求 |
|---|---|---|---|
| kube-apiserver | RESTful API 网关，认证/授权/准入，资源验证 | HTTPS (6443) | 多副本 + 负载均衡 |
| etcd | 分布式键值存储，保存所有集群状态 | gRPC (2379/2380) | 奇数节点集群（3/5/7） |
| kube-scheduler | Pod 调度决策，绑定 Pod 到 Node | 通过 API Server | 多副本 + 选主 |
| kube-controller-manager | 运行控制器循环（Deployment、ReplicaSet、Node 等） | 通过 API Server | 多副本 + 选主 |
| cloud-controller-manager | 与云提供商 API 交互（负载均衡、存储卷等） | 通过 API Server | 可选，多副本 + 选主 |
安全提示：etcd 是控制平面的“单点真相源”，一旦 etcd 被攻破，攻击者可获取所有 Secret、ConfigMap 和集群配置。生产环境必须启用 etcd 的 TLS 双向认证，并限制对 etcd 端口的网络访问。
下图展示了 Kubernetes 控制平面各组件的逻辑架构与交互关系：
2.3 控制平面安全模型
Kubernetes 控制平面安全模型采用多层纵深防御策略，从网络、传输、认证、授权、准入控制到运行时审计，形成完整的信任链。安全模型可归纳为以下四个层次：
- 传输安全层：所有组件间通信必须使用 TLS 加密，防止中间人攻击和窃听。
- 身份认证层：验证请求发起方的身份，支持客户端证书、Bearer 、OpenID Connect 等多种方式。
- 授权决策层：基于 RBAC（基于角色的访问控制）或 ABAC（基于属性的访问控制）判断请求是否被允许。
- 准入控制层：在资源持久化之前，通过 Admission Webhook 执行策略检查（如 OPA/Kyverno 策略）。
常见安全误区：
- 仅依赖防火墙而不启用 RBAC：内部攻击者仍可绕过网络限制直接调用 API。
- etcd 未启用 TLS：攻击者若进入内网，可直接读取 etcd 数据，获取所有 Secret。
- 匿名访问未禁用：kube-apiserver 默认允许匿名请求，生产环境必须显式关闭。
下图展示了控制平面安全模型的请求处理流程与各安全层的拦截点：
2.4 控制平面安全最佳实践清单
| 安全域 | 最佳实践 | 风险等级 |
|---|---|---|
| API Server | 禁用匿名访问；启用审计日志；限制 --insecure-port | 高 |
| etcd | 启用 TLS 双向认证；独立网络隔离；定期备份并加密 | 严重 |
| Scheduler | 限制调度器权限；避免使用 nodeSelector 绕过策略 | 中 |
| Controller Manager | 最小权限 ServiceAccount；禁用不必要的控制器 | 中 |
| RBAC | 遵循最小权限原则；定期审计 Role/ClusterRole 绑定 | 高 |
| Admission Webhook | 部署 OPA/Kyverno 策略引擎；拒绝特权容器和 hostPath 挂载 | 高 |
与 OPA 集成的切入点：OPA 作为准入控制 Webhook 部署在控制平面安全模型的第④层。当 API Server 收到资源创建/更新请求并通过认证和授权后，OPA 会根据预定义的 Rego 策略对请求内容进行校验，只有通过策略检查的请求才会被写入 etcd。这种机制使得安全策略与集群逻辑解耦，实现“策略即代码”。