共计 2427 个字符，预计需要花费 7 分钟才能阅读完成。
作者：Daniel Feldman
介绍
联邦信任域是 SPIFFE 和 SPIRE 最高需求和活跃开发的功能之一。在这篇博文中，我将概述我们当前的计划以及实施它的挑战。
什么是联邦？
SPIFFE 信任域中的证书共享一个信任根。这是一个根信任捆绑包，由使用非标准化格式和协议在控制平面之间和内部共享的多个证书组成。
然而，这还不够好。许多组织都有多个信任根源：可能是因为他们与不同的管理员有不同的组织划分，或者因为他们有偶尔需要沟通的独立的临时和生产环境。类似的用例是组织之间的 SPIFFE 互操作性，例如云供应商与其客户之间的互操作性。这两种用例都需要一个定义明确、可互操作的方法，以便一个信任域中的工作负载对不同信任域中的工作负载进行身份验证。这是联邦。
联邦设计
要实现联邦，我们必须在不同的 SPIFFE 服务器之间共享公钥。这不是一次性操作；由于密钥轮换，每个信任域的公钥会定期更改。每个联邦域必须定期下载其他域的公钥，其频率至少与密钥轮换一样快。
定期下载证书的数据格式尚未最终确定。我们目前的想法是让 SPIFFE 的实现去使用 JWKS 格式，在一个众所周知的 URL 上公开发布证书。然后，要启动联邦关系，实现可以下载 JWKS 数据，并从中导入证书。
我们喜欢 JWKS，因为它是一种通用的、可扩展的格式，用于共享可以容纳 JWT 和 X.509 证书的密钥信息。（出于安全原因，SPIFFE 需要不同的 JWT 和 X.509 标识的密钥材料 – 它们不能只是以不同格式编码的相同公钥。）JWKS 的灵活性允许单个联邦 API 支持 JWT 和 X.509。
工作负载 API
SPIFFE 工作负载 API 提供用于读取联邦公钥的端点。此 API 与用于读取当前信任域的证书的 API 不同，所以应用程序可以区分本地和联邦域的客户端。
SPIRE 的实验支持
虽然它尚未正式标准化为 SPIFFE 的一部分，但是 SPIRE 已经可以提供 JWKS 的实验性实施。
挑战
外部 SPIFFE 服务器的初始身份验证
联邦 API 存在引导问题：如果双方都没有共享信任根，则无法建立初始安全连接。其一种解决方案，是使用两个 SPIFFE 服务器信任的证书颁发机构的 Web PKI。另一种解决方案，是使用手动身份验证机制来消除对公共证书颁发机构（CA）的需求。
SPIRE 使用与节点和工作负载注册类似的方式实现联邦。随着我们扩展注册 API，可以通过该 API 操作联邦，就像节点和工作负载注册一样。
网络中断容错
每次 SPIFFE 实现，从同等的 SPIFFE 实现，导入新证书时，它都会使用上一个已知捆绑包对连接进行身份验证。如果网络中断很长，并且两个 SPIFFE 实现无法通信，超过完整的密钥轮换周期，那么它们将无法继续进行通信，从而破坏了联邦关系。
其一种解决方案，是将密钥轮换间隔，设置为长于可能的最长网络中断长度（或者如果发生长中断，则重新初始化联邦）。这是设计权衡：如果密钥轮换间隔较长，则受损密钥也将在较长时间内保持有效。
或者，如果 Web PKI 可用于 SPIFFE 服务器，则可用于保护联邦连接。我们相信联邦 SPIFFE 服务器之间的 Web PKI，将是一种常见的设计模式，因为它避免了长网络中断导致密钥轮换的问题。
传递与双向联邦
Kerberos 和 Active Directory 具有与联邦相同的，称为“跨领域信任”。在大多数情况下，跨领域信任是双向的（双方互相信任）和传递（如果 A 信任 B，B 信任 C，然后 A 信托 C）。
SPIFFE 中的双向联邦通常（但并非总是如此）是可取的。对于公共 API，API 提供程序可能希望使用 Web PKI 来保护连接的服务器端，并使用 SPIFFE 来保护客户端。因此，我们不会自动配置双向联邦。
对于具有许多信任域的大型组织，传递联邦可以简化实现复杂性。但是，传递联邦可能难以推断 SPIFFE 实现的安全属性。出于这个原因，我们现在没有在 SPIFFE 中实现传递联邦。
目前，用户必须通过添加更多联邦关系，来手动配置传递和双向联邦。
联邦信任域 SVID 的范围
在 Web PKI 中，每个人都信任相同的根证书颁发机构。在 SPIFFE 中，彼此不完全信任的组织可能仍希望联邦其信任域。应用程序必须验证每个 SVID 是否由拥有该信任域的 SPIFFE 服务器颁发。
想象一个奇怪的世界，可口可乐和百事可乐必须交换数据。为此，他们联邦各自的信任域。可口可乐的 SPIFFE 证书根，添加到百事可乐的信托商店，反之亦然。在证书验证的简单实现中，可口可乐服务器可以欺骗性地冒充百事可乐网络上的百事可乐服务器，因为百事可乐信任可口可乐的根证书！
这是问题所在：根证书没有“范围”。任何 CA 都可以为任何名称签署证书。如果所有 CA 都受信任，例如在单个公司内，则可以。在具有多个 CA 的环境中，每个 CA 都应该只允许签署具有特定名称的证书，不然这会导致安全漏洞。
防止这种情况的一种方法是使用 X.509 名称约束扩展。名称约束扩展允许将 CA 证书限制为为特定域名颁发证书。但是，在 TLS 库中对名称约束扩展的支持是有限的，并且它不能解决未来 SPIFFE 身份格式（如 JWT）的问题。由于这些原因，SPIFFE 不包括名称约束扩展。
这意味着所有使用 SVID 的应用程序都必须检查 SVID 中的 SPIFFE ID，是否与签署证书的实际 CA 的信任域匹配。这意味着检查百事可乐 SVID 不是被可口可乐的 CA 签名。当前广泛使用的应用程序（例如 Web 服务器和代理）不执行此检查。
结论
联邦对于 SPIFFE 的成功实施至关重要。但是，以安全和可用的方式实施它仍然存在挑战。我们正在努力与社区一起努力应对这些挑战，如果您有远见，我们很乐意听取您的意见！
要了解有关 SPIFFE 联邦的更多信息：
查看新的 Java SPIFFE Federation Demo，它演示了在 Tomcat 服务器环境中使用 SPIRE 在两个域之间进行联邦。
加入 SPIFFE Slack 与专家讨论 SPIFFE。
加入 SPIFFE SIG-SPEC 双月会议，设计 SPIFFE 联邦会的未来。（不久将有一个单独的联邦工作组。）
