【Linkerd】identity 服务：CSR、mTLS 与工作负载证书轮转

Pod 经注入与重定向后，流量已在 linkerd2-proxy 内终止与发起。两端都是 meshed 时，出站 proxy 需要对目标端点执行 mTLS——证书从哪来、绑定谁的身份、何时失效，由控制面 identity 服务负责。把握手失败一律归咎于「网络不通」，会错过轴 3 上更细的分层：工作负载证书、issuer 与 trust anchor 的轮转语义完全不同。

本篇回答：identity 如何签发与轮转证书，与 Istio SDS 路径差在哪，失败落在哪一层。 发现与端点富化见 第 5 篇；SDS 状态机详见 Envoy 第 11 篇。

本篇在系列中的位置

篇目	核心内容
第 3 篇 · 流量重定向	iptables、CNI
第 4 篇 · identity 服务	CSR、mTLS、issuer / trust anchor
第 5 篇 · destination 架构	四容器 Pod、Informer
系列目录	关键问题、阅读路径

版本锚定：Linkerd 2.20（源码 tag version-2.20）。身份机制对齐 Architecture identity 节与 Automatically Rotating Control Plane TLS Credentials 2.20 文档树。控制面 API 为 linkerd2-proxy-api 的 identity gRPC，非 xDS SDS。无真实集群则不粘贴伪造证书 PEM 或 linkerd check 身份段输出。

一、CSR 与 ServiceAccount 绑定

官方 Architecture 将 identity 服务定义为集群内 TLS Certificate Authority：数据面 proxy 在启动时向 identity 发送 CSR（Certificate Signing Request），identity 校验请求合法性后签发证书，供 proxy-to-proxy 连接实现 mTLS。

绑定关系的核心是 Kubernetes ServiceAccount：签发的工作负载证书身份与 Pod 所使用的 ServiceAccount 对应，而非任意自报 DN。这与 SPIFFE 思路同族——工作负载身份由编排平台主体（K8s SA）锚定；本站不展开 SPIRE 部署全书，只把 Linkerd 视为「集群内 CA + 短期工作负载 cert」工程实现。

协议形状在 linkerd/linkerd2-proxy-api 的 identity gRPC 服务中定义（与 destination、inbound、tap 并列），是 linkerd2-proxy 专用接口，不是通用 xDS 资源类型。proxy 启动 → CSR → 签发 → 本地持有私钥与 cert 链，这条路径在 istio-xds/14 中与 Istio SDS 推送对照：后者把 Secret 当作 xDS 资源订阅，错误落在 ACK/NACK 与 warming 状态机；Linkerd 落在 gRPC 调用与 Secret 侦测（第三节）。

identity Deployment 通常以 gRPC 服务暴露给数据面，并依赖 Kubernetes TokenReview 校验 Pod 使用的 ServiceAccount 与 CSR 主体一致。若 Pod 的 serviceAccountName 被误改或 RBAC 阻止 identity 读取 SA，CSR 会在轴 3 被拒绝，而 destination 仍可能返回端点——表现为「有路由、握手失败」，需与轴 3 空端点区分。

flowchart LR
  proxy["linkerd2-proxy start"] --> csr["CSR over identity gRPC"]
  csr --> validate["identity validates SA"]
  validate --> sign["sign workload cert"]
  sign --> mtls["proxy-to-proxy mTLS"]

图：身份签发是专用 API 一次请求（及后续续期），不是按类型订阅 SDS。

谱系：自动工作负载身份与短期证书是服务网格相对「静态集群 CA + 长证书」的主要卖点；Linkerd 选择把 CA 缩进 独立 identity Deployment，与 destination 故障域分离——identity 不可用会阻断新证书与续期，已持有未过期 cert 的连接可能短期继续。

二、工作负载证书自动轮转

官方文档说明：Linkerd 自动轮转工作负载证书——由 proxy 在证书临近过期时主动发起续期，无需重启 Pod。这是轴 3 上最轻的一层轮转：只影响单个工作负载的 leaf cert，不涉及控制面 reinstall。

机制要点（文档级，非性能宣称）：

• 证书由 identity 签发，寿命相对较短（具体 TTL 以安装配置与版本文档为准）；
• proxy 侦测到期时间并向 identity 重新请求；
• 轮转成功后新连接使用新 cert，与 destination 下发的端点 TLS 身份提示一致。

工作负载层轮转与 SPIFFE 短期 SVID 思路一致：身份绑定工作负载而非节点 IP，泄露窗口受 cert TTL 约束。Linkerd 未实现完整 SPIRE 控制面，而是把 CA 缩进 identity 服务；若组织已标准化 SPIRE，需评估 Linkerd 内置 identity 与外部 CA 的边界（本系列不展开 SPIRE 部署，只标明谱系位置）。

排障时区分：

三、issuer vs trust anchor

工作负载 cert 之上，还有控制面级的 identity issuer 与 trust anchor 两层，轮转重量递增。官方 Automatically Rotating Control Plane TLS Credentials 与架构说明的层级如下：

默认快速安装生成一年期自签 issuer/anchor，适合试用；生产应使用 cert-manager 等外置流程（文档给出 cert-manager + trust-manager 示例）。2.20 公告提及 trust anchor 自动轮转能力的增强方向，但运维上仍须按文档检查清单执行——不能把「工作负载自动轮转」误当成「根证书也会无感轮换」。

flowchart TB
  anchor["trust anchor"]
  issuer["identity issuer cert"]
  leaf["workload certs"]
  anchor --> issuer
  issuer --> leaf

图：信任链三层；越往上轮转越重。leaf 层日常自动化；anchor 层是计划内变更事件。

争论与边界：短期 cert 降低泄露窗口，但提高 identity QPS 与续期失败敏感性；相对「长证书 + 人工轮换」，Linkerd 押注自动化 leaf 轮转。trust anchor 仍常被视为人工或半自动运维事件——这是论文级「零停机根轮换」与生产实践之间的工程间隙，本系列 第 12 篇 展开检查单。

多集群场景下，trust anchor 可跨集群共享而 issuer 按集群独立（官方架构与 cert 文档）。把集群 A 的 issuer Secret 复制到集群 B 不会自动建立互信；跨集群 mTLS 还需 multicluster 扩展与联邦身份规则（第 11 篇规划）。轴 3 排障务必先确认「失败发生在单集群还是联邦路径」。

四、对照 SDS（Envoy 路径）

Istio / Envoy 侧，证书材料通过 SDS 作为 xDS 资源推送到 Envoy：控制面更新 Secret 资源 → proxy 订阅 → Secret 类型 DiscoveryResponse → 热更新 TLS context。失败分为「SDS 未就绪（warming）」与「资源内容非法」等，嵌在通用 xDS 状态机里。

Linkerd 路径对照：

xDS 与专用 API 之争 在身份轴上的体现是：通用协议把失败语义标准化；专用 API 把失败钉在 identity 组件与 K8s Secret 侦测。Neither 单独决定优劣；Linkerd 选型读者应熟悉的是「握手失败先查 identity 轴，而不是查 EDS」。

控制面自身也走 identity：destination、identity、injector 三个 Deployment 的 Pod 同样被注入 linkerd-proxy，控制面组件间 gRPC 亦受 mTLS 保护。identity 服务故障因此具有双重影响：数据面无法续签 leaf cert，控制面组件间通信也可能受阻——排障时看 linkerd-identity Pod 是否 Ready，应同时对照控制面与业务面握手失败是否同时间点爆发。

为何不走 SDS：Envoy SDS 把证书当作可订阅资源，适合「同一控制面服务多种 xDS 客户端」的通用模型（见 envoy/11）。linkerd2-proxy 仅服务 Linkerd，identity API 直接表达 CSR 语义，省去资源类型、版本与 ACK/NACK 层——代价是证书故障排障必须熟悉 identity 组件与 Secret 侦测，而不能套用 istiod 的 warming 口令。

五、失败表象

排障口诀：先 leaf，再 issuer，最后 anchor；并确认两端是否都已 mesh（轴 1）。

证书字段与身份字符串：工作负载 cert 携带与 ServiceAccount 绑定的 SPIFFE 风格身份（具体格式以 2.20 文档为准），destination 在端点元数据中返回「期望 TLS 身份」供 outbound proxy 校验。非 mesh 路径直连 IP 不会走完整身份链；只有 meshed-to-meshed 才强制匹配。

与 cert-manager 集成的轴 3 边界：外置轮转管理 issuer / trust anchor Secret，不改变 proxy CSR 频率。安装前须先让 linkerd 命名空间存在预期证书 Secret，否则 identity 无法启动——injector 仍可能注入 Pod，但新连接握手全失败。

与 destination 的交界：destination 在端点元数据中携带 期望 TLS 身份；identity 提供 实际 cert。握手失败若 leaf 正常，再查 destination 返回的身份是否与 SA 匹配（第 7 篇规划）。不要在未验证 trust anchor 的情况下重装 injector。

时钟与证书：短期工作负载 cert 对节点时钟漂移敏感。若 NTP 大幅偏差，可能出现「尚未过期但对端认为无效」的握手失败——这类问题落在轴 3 与节点运维的交界，而非 destination 空端点。生产环境应保证 kubelet 与节点时间同步，与 cert-manager 轮转窗口一并纳入变更窗口检查单（第 12 篇）。

2.20 与 trust anchor 自动化：2.20 公告将 trust anchor 自动轮转列为能力增强方向；无论自动化程度如何，根轮换仍比 leaf 轮转重，必须与全网格滚动计划联动。轴 3 排障切勿把「工作负载 cert 自动续期」推广到「根证书也会无感变更」。

参考资料

规范 / 官方文档 / 源码（A）

• Linkerd, Architecture（identity 服务、CSR、mTLS）
• Linkerd, Automatically Rotating Control Plane TLS Credentials（三层证书与 cert-manager 集成）
• linkerd/linkerd2-proxy-api（identity gRPC 定义）
• Linkerd, Announcing Linkerd 2.20（trust anchor 自动化相关说明）

站内对照

• Envoy 第 11 篇 · Warming / SDS
• Istio 14 · Linkerd 对照
• Linkerd 第 3 篇 · 流量重定向

学术 / 身份谱系（A）

• SPIFFE 工作负载身份模型（SPIFFE 规范；Linkerd 与之同族但实现为内置 identity）

上一篇：流量重定向

下一篇：destination 架构