4. 多集群身份与认证：X.509证书体系、ServiceAccount跨集群使用、OIDC与多集群集成

4.1 多集群身份认证的核心挑战

在多集群架构中，每个集群拥有独立的CA（证书颁发机构）和身份管理系统。当工作负载或管理员需要跨集群访问资源时，身份认证面临三个核心挑战：

• 信任锚不一致：集群A签发的证书在集群B的CA信任链中无效。
• 凭证生命周期不同步：各集群的、证书过期时间独立管理，缺乏统一轮换机制。
• 身份映射缺失：集群A的ServiceAccount在集群B中没有对应的RBAC绑定。

4.2 X.509证书体系：集群间信任的基石

Kubernetes原生使用X.509证书作为kube-apiserver与kubelet、kubectl之间的TLS认证基础。在多集群场景下，证书体系需要扩展为“根CA联邦”或“中间CA代理”。

4.2.1 单集群证书结构回顾

4.2.2 多集群证书联邦方案

实现跨集群证书信任的两种主流模式：

• 共享根CA模式：所有集群使用同一个根CA签发证书。优点：天然信任；缺点：根CA泄露风险极高，集群解耦困难。
• 中间CA代理模式：每个集群保留独立根CA，通过一个“联邦中间CA”签发跨集群通信证书。联邦中间CA的证书被所有集群信任。

4.3 ServiceAccount跨集群使用

ServiceAccount（SA）是Pod内进程访问Kubernetes API的凭证载体。默认情况下，SA的JWT 仅在本集群有效。跨集群使用SA需要解决的“可移植性”和“信任传递”。

4.3.1 跨集群SA 交换流程

1. 源集群SA获取：Pod使用挂载的SA （JWT）向源集群apiserver发起请求。
2. 交换代理：源集群的代理组件将SA 发送给目标集群的 Review API进行验证。
3. 身份映射：目标集群根据中的`sub`（Subject）或`iss`（Issuer）字段，映射到本地RBAC绑定。
4. 返回临时凭证：目标集群签发一个短期客户端证书或新的JWT ，供Pod后续调用。

4.3.2 跨集群SA配置示例

在源集群创建SA并绑定RBAC，允许其访问目标集群的指定资源：

# 源集群：创建SA
apiVersion: v1
kind: ServiceAccount
metadata:
  name: cross-cluster-sa
  namespace: default
---
# 源集群：创建ClusterRole和ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: cross-cluster-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: cross-cluster-reader-binding
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cross-cluster-reader
subjects:
- kind: ServiceAccount
  name: cross-cluster-sa
  namespace: default

# 目标集群：创建TokenReview和RBAC映射（通过代理组件自动完成）
# 代理组件配置示例（伪代码）
tokenReview:
  issuer: https://source-cluster.example.com
  audience: https://target-cluster.example.com
rbacMapping:
  subject: "system:serviceaccount:default:cross-cluster-sa"
  clusterRole: "target-pod-reader"

4.4 OIDC与多集群集成

OpenID Connect（OIDC）是Kubernetes官方推荐的集群外部身份认证协议。通过OIDC，多集群可以共享同一个身份提供者（IdP），实现统一的用户和ServiceAccount认证。

4.4.1 OIDC多集群架构

• 统一IdP：所有集群配置同一个OIDC Issuer（如Dex、Keycloak、Azure AD）。
• 集群独立配置：每个集群的apiserver通过`--oidc-issuer-url`、`--oidc-client-id`等参数指向IdP。
• 断言：用户或SA从IdP获取ID ，携带给任意集群的apiserver进行验证。

4.4.2 OIDC与ServiceAccount结合

Kubernetes 1.20+支持ServiceAccount 投射（Projected ），可以配置OIDC作为的验证后端。这使得SA 可以被OIDC IdP验证，实现SA级别的跨集群认证。

4.4.3 多集群OIDC配置要点

• Issuer一致性：所有集群的`--oidc-issuer-url`必须指向同一个IdP，且IdP的证书链被所有集群信任。
• Client ID管理：每个集群可以注册独立的Client ID，但建议使用同一个Client ID简化管理。
• Claims映射：通过`--oidc-username-claim`和`--oidc-groups-claim`将IdP中的用户属性映射到Kubernetes RBAC。
• 验证：确保IdP的JWKS（JSON Web Key Set）端点可被所有集群网络访问。

4.5 三种认证方案的对比与选型