服务网格 19：工作负载身份和证书怎样建立

Pod 的名字不是它在网格中的身份

orders → inventory 需要回答的问题不是“库存 Pod 的 IP 是什么”，而是“连接对端以什么身份出现，以及谁担保了这个身份”。Pod IP、Deployment 名称和容器镜像都可能变化；在 Istio 的 Kubernetes 部署中，工作负载通常以命名空间和 ServiceAccount 表示身份。典型的 SPIFFE 形式是 spiffe://<trust-domain>/ns/<namespace>/sa/<service-account>。例如实验信任域为 cluster.local、命名空间为 service-mesh-lab 时，orders 和 inventory 若使用不同 ServiceAccount，就应呈现不同的身份；cluster.local 是示例值，不是所有集群固定使用的值。

身份字符串与证明身份的凭据不是一回事。创建 Pod 时指定 ServiceAccount 是期望身份；实际代理获得并使用的短期 X.509 证书、证书链和对端在握手时的验证结果，才是另一组可核查的证据。反过来，持有一张有效证书也不自动获得所有服务的调用权限：第 21 篇仍要单独做授权。

ServiceAccount 标识身份，agent 经 CA 申请证书并通过 SDS 交给代理；签发和使用均需实测

从 ServiceAccount 到代理证书

Istio 的身份供应路径涉及工作负载的 Kubernetes 凭据、同 Pod 中的 Istio agent、CA 与 Envoy。agent 以工作负载凭据向签发服务申请证书；CA 在验证请求后签发，agent 经 SDS 向代理提供证书材料，代理用于 mTLS。具体 CA、信任域、证书有效期和轮换参数都取决于实际安装配置，不能用概念图推导本环境已经签发了哪张证书。CSR 中包含申请公钥，私钥不应当为了文章取证而导出。

轮换也有两个不同的事实：控制面/agent 具备自动轮换机制，与一次实验中观察到新的证书，不能互相替代。验收时对同一工作负载在轮换前后采集只含公开信息的证书摘要、序列号、SAN、签发者和有效期，并核对握手仍成功、旧证书确实退出活跃配置。Pod 被重建后拿到新证书不等于观察了运行中轮换；为节省时间缩短有效期只能在隔离测试配置中进行，须记录改变过的参数。

用累计服务链验明身份

先在隔离集群部署 examples/service-mesh/ 的 frontend → orders 调用链（orders 先调用 inventory，成功后再调用 external-stub）。当前应用默认监听 127.0.0.1，未来的 Pod 部署需显式改为适合跨 Pod 调用的监听地址；进程基线不能直接当成 Kubernetes 验收。为 orders 和 inventory 分配不同的测试 ServiceAccount，保留 Deployment、Pod 实际 serviceAccountName 与命名空间；向 inventory 发一个带唯一 X-Request-ID 的请求，再核对代理使用的证书公开元数据及对端身份。

负例先只改变 orders 的 ServiceAccount：预期身份随之改变，但没有授权限制时，请求未必失败。若要进一步验证不可信证书被拒绝，必须在隔离环境另建错误信任根的客户端，记录握手失败和目标代理证据，不用“换了 ServiceAccount 后正常失败”冒充 CA 拒绝。不要把私钥、ServiceAccount token、JWT 或未经脱敏的 Envoy secret dump 放入证据目录。

待验收项	判据	本文记录
正例：主体与信任链	实际 Pod、公开证书 SAN/链与代理连接中的身份一致	NOT_RUN：无 Kubernetes/Istio/Envoy
负例：更换 ServiceAccount	身份确实改变；是否被拒绝按策略和连接证据另判	NOT_RUN
运行中轮换	同一工作负载前后公开证书信息改变，调用持续可核对	NOT_RUN

实验必须先确认隔离 context，并在 writing-plans/service-mesh/VERSIONS.md 冻结 Kubernetes、Istio、镜像与信任域；本文不提供虚构的证书序列号、过期时间或运行日志。

练习与参考解答

两个 Pod 都叫 inventory，为什么不能推断它们拥有相同的工作负载身份？参考解答：需要核对命名空间、ServiceAccount、信任域和实际证书 SAN；名称本身不在身份公式里。
更换 orders 的 ServiceAccount 后仍能访问库存，能证明证书没有更新吗？参考解答：不能。要先读实际 Pod 和代理所用证书；即便身份改变，只要没有相应的拒绝策略，访问仍可能成功。