研发中：联邦SPIFFE信任域

作者：Daniel Feldman

介绍

联邦信任域是SPIFFE和SPIRE最高需求和活跃开发的功能之一。在这篇博文中，我将概述我们当前的计划以及实施它的挑战。

什么是联邦？

SPIFFE信任域中的证书共享一个信任根。 这是一个根信任捆绑包，由使用非标准化格式和协议在控制平面之间和内部共享的多个证书组成。

然而，这还不够好。许多组织都有多个信任根源：可能是因为他们与不同的管理员有不同的组织划分，或者因为他们有偶尔需要沟通的独立的临时和生产环境。类似的用例是组织之间的SPIFFE互操作性，例如云供应商与其客户之间的互操作性。这两种用例都需要一个定义明确、可互操作的方法，以便一个信任域中的工作负载对不同信任域中的工作负载进行身份验证。这是联邦。

联邦设计

要实现联邦，我们必须在不同的SPIFFE服务器之间共享公钥。这不是一次性操作；由于密钥轮换，每个信任域的公钥会定期更改。每个联邦域必须定期下载其他域的公钥，其频率至少与密钥轮换一样快。

定期下载证书的数据格式尚未最终确定。我们目前的想法是让SPIFFE的实现去使用JWKS格式，在一个众所周知的URL上公开发布证书。然后，要启动联邦关系，实现可以下载JWKS数据，并从中导入证书。

https://tools.ietf.org/html/rfc7517

我们喜欢JWKS，因为它是一种通用的、可扩展的格式，用于共享可以容纳JWT和X.509证书的密钥信息。（出于安全原因，SPIFFE需要不同的JWT和X.509标识的密钥材料 - 它们不能只是以不同格式编码的相同公钥。）JWKS的灵活性允许单个联邦API支持JWT和X.509 。

工作负载API

SPIFFE工作负载API提供用于读取联邦公钥的端点。此API与用于读取当前信任域的证书的API不同，所以应用程序可以区分本地和联邦域的客户端。

https://github.com/spiffe/spiffe/blob/master/standards/SPIFFE_Workload_API.md

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不包括名称约束扩展。

https://tools.ietf.org/html/rfc5280#section-4.2.1.10

这意味着所有使用SVID的应用程序都必须检查SVID中的SPIFFE ID，是否与签署证书的实际CA的信任域匹配。这意味着检查百事可乐SVID不是被可口可乐的CA签名。当前广泛使用的应用程序（例如Web服务器和代理）不执行此检查。

结论

联邦对于SPIFFE的成功实施至关重要。但是，以安全和可用的方式实施它仍然存在挑战。我们正在努力与社区一起努力应对这些挑战，如果您有远见，我们很乐意听取您的意见！

要了解有关SPIFFE联邦的更多信息：

• 查看新的Java SPIFFE Federation Demo，它演示了在Tomcat服务器环境中使用SPIRE在两个域之间进行联邦。
• 加入SPIFFE Slack与专家讨论SPIFFE。
• 加入SPIFFE SIG-SPEC双月会议，设计SPIFFE联邦会的未来。 （不久将有一个单独的联邦工作组。）

https://github.com/spiffe/spiffe-example/tree/master/java-spiffe-federation-jboss

http://spiffe.slack.com/

https://github.com/spiffe/spiffe