4、多集群环境概述：Kubernetes多集群架构模式（Hub-Spoke、Federation、Cluster API）
在镜像供应链安全巡检场景中，单一集群往往无法覆盖企业级交付链路。多集群架构的选择直接决定了安全策略的传播方式、镜像签名的验证路径以及凭证管理的复杂度。本节从三种主流多集群模式出发，分析其拓扑结构、适用场景及安全运维特征。
4.1 多集群架构的核心驱动力
企业采用多集群的原因通常包括：
- 环境隔离：开发、测试、生产集群分离，防止镜像误推或配置泄漏。
- 地理分布：降低镜像拉取延迟，满足数据主权合规要求。
- 故障域隔离：单个集群故障不影响全局交付流水线。
- 租户隔离：多团队共享基础设施时，通过独立集群实现安全边界。
安全视角提示： 多集群架构并非天然安全。镜像签名验证、策略分发、凭证同步等环节若未统一治理，反而会扩大攻击面。选择架构模式时，需同步规划跨集群的 Sigstore 信任锚点。
4.2 三种主流多集群架构模式对比
| 架构模式 | 控制面关系 | 典型工具 | 安全策略传播 | 镜像供应链适用场景 |
|---|---|---|---|---|
| Hub-Spoke | 中心控制面管理多个工作集群 | Open Cluster Management (OCM)、Rancher | 中心下发，Spoke 被动接收 | 统一镜像仓库访问控制、全局签名策略下发 |
| Federation | 多个控制面对等同步 | KubeFed (Kubernetes Federation v2) | 双向同步，需处理冲突 | 跨集群镜像资源模板化部署，签名策略需协调 |
| Cluster API | 声明式集群生命周期管理 | Cluster API (CAPI) + Provider | 通过 Bootstrap 和 ControlPlane 模板注入 | 集群创建时预置 Sigstore 组件和信任证书 |
4.3 Hub-Spoke 架构模式
Hub-Spoke 是目前生产环境最广泛采用的多集群模式。一个中心集群（Hub）通过 API 聚合的方式管理多个工作集群（Spoke）。Hub 不运行用户工作负载，仅负责策略下发、资源分发和状态收集。
- 拓扑特征：Hub 集群持有所有 Spoke 集群的 kubeconfig 凭证；Spoke 集群之间通常不直接通信。
- 安全优势：镜像签名验证策略（如 Kyverno ClusterPolicy）可在 Hub 上定义，通过 ManifestWork 分发到所有 Spoke；Hub 可集中审计镜像拉取日志。
- 安全风险：Hub 集群成为单点攻击目标；若 Hub 被攻陷，所有 Spoke 集群的凭证和策略均可能被篡改。
镜像供应链实践： 在 Hub 集群部署 Sigstore Policy Controller，通过 OCM 的 Placement 规则将策略绑定到指定 Spoke 集群的命名空间。Spoke 集群无需额外安装验证组件，仅需信任 Hub 下发的公钥。
4.4 Federation 架构模式
Federation 模式通过 KubeFed 实现跨集群资源同步。与 Hub-Spoke 不同，Federation 的控制面是对等的：每个集群都运行 Federation 组件，通过 API 同步资源模板和覆盖策略。
- 拓扑特征：所有集群处于平等地位；资源通过
FederatedDeployment、FederatedConfigMap等 CRD 定义。 - 安全优势：无中心单点；镜像签名策略可定义为 FederatedClusterPolicy，自动同步到所有成员集群。
- 安全风险：策略冲突处理复杂；若某个集群被攻陷，恶意策略可能反向同步到其他集群。
镜像供应链避坑： Federation 模式下，Sigstore 的信任根（Root of Trust）必须在所有集群间保持一致。建议使用外部密钥管理服务（KMS）统一签发和轮换密钥，避免因集群间时间偏差导致签名验证失败。
4.5 Cluster API 架构模式
Cluster API（CAPI）是 Kubernetes SIG 推出的声明式集群生命周期管理工具。它通过 Cluster、Machine、MachineDeployment 等 CRD 定义集群的期望状态，由 Provider（如 AWS、vSphere、OpenStack）负责实际创建。
- 拓扑特征：管理集群（Management Cluster）运行 CAPI Controller；工作集群（Workload Cluster）由管理集群声明式创建和升级。
- 安全优势：可在集群创建时通过 Bootstrap 模板注入 Sigstore 组件和信任证书，实现“安全左移”。
- 安全风险：管理集群的凭证权限极高；若管理集群被攻陷，攻击者可创建带有后门镜像的集群。
安全水位巡检集成： 在 Cluster API 的 Bootstrap 阶段，使用
KubeadmConfigTemplate 的 preKubeadmCommands 安装 cosign 和 policy-controller，并将 Rekor 公钥写入 /etc/sigstore/。这样每个新建集群自动具备镜像签名验证能力。
4.6 架构模式选择建议
针对镜像供应链安全水位巡检场景，三种模式的选择建议如下：
| 场景特征 | 推荐模式 | 理由 |
|---|---|---|
| 已有中心化运维团队，集群数量 10+ | Hub-Spoke | 策略集中下发，审计日志统一收集，适合 Sigstore Policy Controller 全局部署 |
| 多团队自治，集群规模中等（3-8） | Federation | 资源模板化同步，各团队可保留本地策略覆盖，但需协调信任根 |
| 基础设施即代码，集群频繁创建/销毁 | Cluster API | 声明式安全注入，集群创建即具备签名验证能力，适合 GitOps 流水线 |
| 混合模式（部分固定集群 + 部分弹性集群） | Hub-Spoke + Cluster API | Hub 管理固定集群，CAPI 管理弹性集群，统一通过 Hub 下发安全策略 |