说明短期有效的 SPIFFE/SPIRE SVIDs 为何仍依赖节点完整性、实验室中的 cgroup 伪造测试揭示了什么，以及哪些 Kubernetes 控制措施可以限制影响。
SPIFFE 为服务提供短期有效的密码学身份凭证，称为 SVIDs。工作负载可以使用这些凭证建立 TLS 连接，或签名和验证 JWTs。SPIFFE 官方概述定义了这一模型。
身份判定在哪里进行
SPIRE 在签发 SVIDs 之前，会进行节点证明和工作负载证明。在工作负载证明过程中，SPIRE 代理从操作系统内核、同一节点上的 kubelet 等本地来源获取进程属性，然后将这些属性与注册条目中的选择器条件进行比较。匹配成功后，即可确定该进程获得哪个 SPIFFE ID。SPIRE 概念文档介绍了这一机制。
实验室研究发现的适用范围
在这一模型中，SVID 在密码学上是否有效，与它是否签发给了预期进程，是两个不同的问题。Unit 42 的实验室研究表明，已经拥有 Kubernetes 节点 root 权限的攻击者可以伪造 Linux cgroup 信息，欺骗 SPIRE 代理，从而获得属于同一节点上另一工作负载的有效 SVID。具体技术流程见Unit 42 的研究。
Unit 42 明确表示，尚未在真实攻击中观察到这一技术。因此，这项发现并非存在实际利用的证据，而是描述了攻击者取得 root 权限、破坏节点信任后产生的一种后渗透风险。
针对节点风险的防御模型
在防御规划中，应将节点失陷视为该节点范围内所有工作负载身份均已失陷。Unit 42 的建议包括限制特权容器和对宿主机的直接访问，同时减少对薄弱或易于伪造的选择器的依赖。这里涉及的是已失陷节点的范围，并不自动延伸至整个集群。
减少 pod 和节点的权限
Kubernetes Pod Security Standards 中的 Restricted 配置要求禁止特权 pod、阻止权限提升，并让容器以非 root 用户身份运行。官方安全检查清单还指出，seccomp 可以缩小容器内可调用的 Linux 内核系统调用范围。详情见 Pod Security Standards 和 Kubernetes 安全检查清单。
将选择器视为信任边界的一部分
选择器不仅仅是匹配细节：它们决定哪些本地属性会被纳入证明判定。因此，审查时应考虑每项条件使用了哪些操作系统或 kubelet 数据，以及拥有 root 权限后是否容易伪造这些数据。目标是依赖能够精确区分工作负载的选择器，而非宽泛或薄弱的条件。
敏感级别隔离与额外凭据
Kubernetes 还建议将不同敏感级别的工作负载部署在不同节点上，并且不要向不需要服务账户令牌的 pod 挂载此类令牌。这两项控制措施均见于官方安全检查清单。
节点隔离旨在让攻击者在容器逃逸后更难直接转向更敏感的应用。不挂载不必要的服务账户令牌，也可以避免 pod 内存在一份独立于 SVID 的额外凭据。
实用的审查步骤
可以围绕这一信任边界制定一套简短的审查流程，同时考虑配置和工作负载的部署位置：
身份范围：每个节点的范围内有哪些 SPIFFE IDs？哪些敏感级别的工作负载共用该节点？
证明输入：选择器使用了哪些操作系统或 kubelet 数据？拥有 root 权限后能否伪造这些数据？
节点权限：哪些 pod 具有特权、能够访问宿主机、允许权限提升，或以 root 身份运行？
额外凭据：哪些 pod 虽然不需要服务账户令牌，却仍然获得了此类令牌？
结论并不是 SVIDs 没有价值。评估其密码学身份保证时，必须同时考虑执行证明的节点是否保持完整。具备韧性的模型应将短期有效的工作负载身份与 pod 加固、精确的选择器条件、按敏感级别进行的节点隔离，以及不必要凭据的移除结合起来。
