云原生工作负载身份，是为运行中的应用实例、服务或 Pod 建立唯一、可验证、可持续轮换的身份，并以此作为访问控制、通信加密和权限管理的依据。它回答的不是“请求来自哪个 IP”，而是“哪个工作负载正在访问什么资源，以及它是否被授权”。
这一概念源于云原生环境对传统网络边界的冲击。微服务数量增加后，服务间东西向通信成为常态；Pod 会随着发布、扩缩容和调度在节点之间变化，IP 地址也可能动态改变。此时，单纯依赖内网、VPN、防火墙或固定 IP 规则来判断信任关系，既难以维护，也无法有效限制攻击者在集群内部横向移动。
工作负载身份如何发挥作用
工作负载身份通常具备三个特征：身份粒度更细、凭证生命周期更短、验证过程更自动化。与多个服务共享一个账号不同，它要求不同工作负载拥有相互独立的身份凭证，并通过自动签发和轮换降低凭证长期暴露的风险。
在 Kubernetes 生态中，SPIFFE 定义了工作负载身份的格式和验证方式；Service Mesh 可以借助 Envoy Sidecar，为服务间通信提供身份验证和 mTLS 加密。这样，访问控制就能从“网络是否可达”细化为“身份是否被授权”，通信也不再默认信任集群内部的流量。
它解决什么问题
工作负载身份的核心价值，是缩小信任范围。当一个 Pod 被攻破时，攻击者获得的凭证理论上只对应这个工作负载，不能自然扩展为其他服务的访问权限。服务间通信经过身份验证和加密后，中间人攻击以及基于网络位置的越权访问会更难实施。
但它不是网络安全的替代品，也不是部署后自动生效的“安全开关”。企业仍需梳理服务依赖、定义授权策略、处理遗留系统兼容性，并评估 mTLS、代理和证书管理带来的性能与运维成本。对于服务间调用少、横向移动威胁不明显的架构，全面引入这套体系未必划算。
因此，判断是否适合建设工作负载身份，关键不在于是否已经使用云原生技术，而在于是否存在高密度东西向通信、动态工作负载和真实的横向访问风险。满足这些条件时，身份才应成为云原生安全边界的核心锚点。