工作负载身份把动态进程认证从网络位置和静态密钥中分离

工作负载身份用于识别正在运行的软件进程、容器或服务实例。传统做法常把长期密钥写进配置，或根据 IP 和网络区段推断身份；在实例频繁创建、迁移和销毁的环境中，这些方法难以轮换，也不能可靠说明请求来自哪个工作负载。

身份不是网络位置

IP 地址、主机名和命名空间可以参与证明，但不应独自成为最终身份。地址会复用，代理会改变连接来源，同一节点上也可能运行多个权限不同的进程。工作负载身份需要绑定到可验证的运行属性，并由受信任控制面签发短期凭据。

SPIFFE 使用 URI 形式的 SPIFFE ID 表达工作负载身份，并通过 SVID 提供可验证凭据。X.509-SVID 可用于双向 TLS，JWT-SVID 可在适当场景作为令牌。身份命名方案应稳定表达信任域和工作负载归属，不应把易变的 Pod 名称或部署副本编号编码为长期授权语义。

信任域定义一组共同信任根和身份管理边界。组织、环境和集群怎样划分信任域，决定联邦、隔离和事故影响范围。为了方便把所有环境放进同一域，会扩大信任；每个小单元单独建域又增加联邦和运维成本。

身份系统先证明节点，再依据进程属性证明工作负载。可验证属性可能来自云实例身份、调度器元数据、容器标签、进程用户或经过签名的部署信息。选择器必须由可信组件观察，不能只相信工作负载自己声明的标签。

SPIFFE Workload API 通过本地端点向工作负载交付身份材料。规范依赖带外机制识别调用者，因此本地端点的权限和宿主隔离非常重要。任何能冒充目标进程访问端点的主体，都可能获得相同凭据。

应用不应把私钥长期写入文件或镜像。身份代理可以在内存或受控接口中提供凭据，并在到期前推送轮换。客户端和服务端都要支持不中断连接的轮换；只缩短证书期限而应用仍缓存旧凭据，会造成周期性故障。

验证 SVID 能确认对方拥有某个身份，但不说明它可以读取哪项数据或调用哪个操作。授权策略仍需基于资源、动作、环境和上下文决定。把身份字符串中的路径片段直接当作所有授权规则，容易让命名调整变成权限变更。

策略应默认拒绝，并为服务到服务、作业到数据库和运维访问分别建模。高风险操作可能还需要用户委托、审批或设备状态。零信任架构强调每次访问都根据资源和上下文判断，而不是因为请求已经位于某个内部网络就默认放行。

身份传播也要受控。入口服务代表最终用户调用下游时，需要区分入口自身身份与用户委托上下文。直接把用户令牌无限转发会扩大受众和泄漏面；完全丢弃用户上下文又可能让下游无法执行细粒度授权。

跨信任域通信需要交换和验证信任包，并限制哪些域、身份和服务可以互通。联邦不是把两个域合成一个域，而是建立明确的外部信任关系。信任包更新、根轮换和时钟偏差都应演练。

短期凭据减少长期密钥泄漏风险，但撤销通常依赖较短有效期和策略阻断。控制面不可用时，已经签发的凭据可能继续有效，新实例却无法取得身份。系统要在安全和可用性之间定义缓存、宽限和拒绝策略，不能在故障时自动退回共享静态密钥。

监控应覆盖签发失败、轮换延迟、过期凭据、未知信任域、策略拒绝和身份使用异常。日志记录身份和决策依据，但不记录私钥或完整敏感令牌。事故响应要能定位某个身份在哪些节点、时间和资源上使用。

引入工作负载身份应先建立清晰的服务清单、所有者和调用关系，再选择身份命名。若现有系统仍用共享数据库密码，可以逐个客户端迁移，保持双机制窗口尽量短，并通过遥测确认旧凭据不再使用。

验收不能只测试正常握手，还要覆盖身份错误、信任域错误、凭据过期、轮换中连接、控制面中断和策略撤销。审计应能从资源访问追到工作负载身份、部署版本和节点证明。

工作负载身份解决的是“谁在运行并发起请求”。资源权限、业务授权、用户委托和数据治理仍是独立问题，不能由一张短期证书自动完成。

短期证书与令牌依赖可靠时间。节点时钟偏差可能让新凭据尚未生效或提前过期，因此时间同步和允许偏差需要监控。签发端的随机数、密钥保护和审计同样属于信任链。身份控制面备份不能只保存数据库，还要明确根密钥恢复、轮换连续性和恢复后旧凭据的处理方式。

恢复演练应验证新旧信任包过渡期间双方都能按计划通信，并确认过渡窗口结束后旧根确实不再被接受。