研发中：联邦SPIFFE信任域

做者：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联邦会的将来。 （不久将有一个单独的联邦工做组。）