2、租户签名链路概述：多租户场景、签名机制、链路拓扑基本元素

在云原生与微服务架构中，ConfigMap 作为配置管理的核心对象，其变更直接影响下游服务的运行行为。当引入多租户签名机制后，ConfigMap 的变更不再仅仅是键值对的更新，而是触发一条包含身份验证、签名校验与拓扑重算的完整链路。本章从多租户场景出发，拆解签名机制的核心流程，并定义链路拓扑中的三个基本元素：服务、网关与签名节点。

2.1 多租户场景与签名需求

多租户（Multi-Tenancy）是 Kubernetes 集群中常见的资源隔离模式。不同租户（团队、项目或业务线）共享同一套控制面，但彼此的数据与配置必须严格隔离。ConfigMap 作为租户间共享或独享的配置载体，其变更需要满足以下安全约束：

• 身份可信：只有经过认证的租户身份才能发起 ConfigMap 变更。
• 内容防篡改：ConfigMap 数据在传输与存储过程中不能被中间人篡改。
• 变更可追溯：每次变更必须携带租户签名，便于审计与回滚。

2.2 签名机制核心流程

签名机制采用非对称加密与摘要算法相结合的方式。每个租户拥有唯一的密钥对（私钥签名、公钥验证）。ConfigMap 变更的签名流程包含以下步骤：

1. 摘要计算：对 ConfigMap 的完整内容（包括 metadata、data 字段）计算 SHA-256 摘要。
2. 私钥签名：租户使用自己的私钥对摘要进行加密，生成签名值。
3. 签名注入：将签名值、租户 ID、时间戳写入 ConfigMap 的 annotation 中。
4. 公钥验证：消费端（网关或签名节点）从租户公钥池中获取对应公钥，解密签名并与本地摘要比对。

2.3 链路拓扑基本元素

租户签名链路拓扑由三个基本元素构成：服务（Service）、网关（Gateway）与签名节点（Signing Node）。三者协同完成 ConfigMap 变更的签名、验证与流量转发。

• 服务（Service）：ConfigMap 的最终消费者。服务实例在启动或热更新时，从 API Server 拉取 ConfigMap，并依赖签名节点验证签名有效性。
• 网关（Gateway）：流量入口与策略执行点。网关拦截 ConfigMap 变更请求，校验租户身份，并将签名后的变更转发至签名节点进行深度验证。
• 签名节点（Signing Node）：签名与验证的执行单元。签名节点维护租户密钥池，执行摘要计算、签名生成与签名验证，并将验证结果写回 ConfigMap 的 status 字段。

2.4 元素间交互关系

三个基本元素之间的交互遵循请求-验证-消费的三角模型。网关作为流量入口，签名节点作为安全锚点，服务作为最终执行者。下表总结了各元素之间的通信协议与数据流：

2.5 签名链路中的 ConfigMap 变更流程

结合三个基本元素，一次完整的 ConfigMap 签名变更流程如下：

1. 租户发起变更：租户通过 CLI 或 UI 提交 ConfigMap 变更请求，请求中包含租户 ID 与原始配置内容。
2. 网关拦截与校验：网关提取租户 ID，校验该租户是否有权修改目标 ConfigMap（基于 RBAC 或自定义策略）。
3. 签名节点签名：网关将 ConfigMap 摘要与租户 ID 转发至签名节点，签名节点使用租户私钥生成签名，并返回签名值。
4. ConfigMap 更新：网关将签名值、租户 ID、时间戳写入 ConfigMap 的 annotation（例如 signature.tenant.io/signature），然后通过 Kubernetes API 更新 ConfigMap。
5. 服务实例验证：服务实例在 Watch 到 ConfigMap 变更后，向签名节点发起验证请求，签名节点使用租户公钥解密签名并与本地摘要比对，返回验证结果。
6. 配置生效：验证通过后，服务实例加载新配置；验证失败则回滚至上一版本并告警。

2.6 拓扑变更的触发条件

链路拓扑并非静态，以下场景会触发拓扑变更：

• 租户新增/删除：新租户注册时，签名节点需动态加载其公钥；租户注销时，需从密钥池中移除对应公钥并清理关联 ConfigMap。
• 服务扩缩容：服务实例数量变化时，网关的路由规则与签名节点的验证负载需要同步调整。
• 签名密钥轮换：租户定期轮换密钥对时，签名节点需在 TTL 窗口内完成新旧密钥的平滑切换，避免验证中断。
• 网关故障转移：主网关宕机后，备用网关接管流量，签名节点需重新建立与备用网关的 mTLS 连接。