云原生零信任的关键，不是把传统网络边界搬到容器平台，而是把“工作负载身份”确立为访问决策的核心依据。请求是否被允许，不能只看流量来自哪个网络、节点或集群，还要判断发起请求的工作负载是谁、由哪个应用或团队创建、当前运行在哪里、承担什么业务职责，以及正在访问何种资源。
从网络位置转向工作负载身份
云原生环境中的容器、服务和任务具有短生命周期，并可能随着调度在不同节点之间迁移。若权限仍绑定于固定地址、长期密钥或共享账号，网络位置一旦变化，原有授权就难以准确反映真实风险。工作负载身份则能够把应用、服务、任务、租户和运行环境关联起来，使授权从“内部流量默认可信”转向“请求主体必须持续证明其合理性”。
身份设计应优先遵循三项原则：服务身份优先于共享账号，短时授权优先于长期凭据，权限范围应基于实际调用关系而非网络位置。任务结束后，临时权限也应能够自动回收，避免凭据和访问能力残留。
身份必须进入平台控制链路
工作负载身份不能只停留在认证系统中，还要进入应用交付、算力调度和运行时控制。部署前，平台应识别工作负载是否需要高权限、访问敏感数据或使用特殊节点；调度时，应结合租户、环境、节点属性和数据敏感度进行约束；运行期间，则持续检查其调用对象和访问范围是否仍符合业务职责。
这使零信任从一次性的登录判断，转变为贯穿生命周期的持续评估。一个原本只负责业务处理的服务，如果突然扩大调用范围，开始访问无关数据服务，或者出现跨租户通信，就应触发重新评估，而不是因为“已经部署在内网”而继续放行。
从身份走向可解释授权
工作负载身份的价值，最终体现在授权可解释、策略可执行、异常可追踪。企业应先梳理工作负载清单、服务调用关系、节点与租户关系，以及核心数据访问路径，再把关键控制嵌入交付和调度流程。对于高价值工作负载和敏感数据，优先建立细粒度策略；对普通业务，则可采用较为简化的隔离方式，避免过度控制带来性能和运维负担。
零信任并不意味着所有请求都必须经过复杂检查，而是要求每次关键访问都有明确主体、业务目的和权限边界。只有当工作负载身份能够随算力移动，并被网络、调度、运行时和数据系统共同理解，云原生环境中的“默认不信任”才真正具备落地基础。