扩展 SPIRE 可以通过嵌套拓扑和联合拓扑来实现。嵌套拓扑允许将多个 SPIRE 服务器链接在一起，以发放属于同一信任域的身份。联合拓扑用于在不同信任域之间建立信任，使工作负载能够在不同信任域中进行身份验证。SPIRE 还可以与其他 SPIFFE 兼容系统和 OIDC 提供者系统进行联合，以实现安全的身份验证和通信。在部署规模时，需要考虑 SVID 和根证书的生存时间、工作负载数量和分布、JWT-SVID 的使用等因素，并注意数据存储的设计和规划。

SPIRE 部署可以根据工作负载的增长来调整大小或规模。一个 SPIRE 部署由一个或多个共享复制数据存储的 SPIRE 服务器组成，或者相反，由在同一信任域中的一组 SPIRE 服务器和至少一个 SPIRE 代理（通常是一个以上）组成。

部署的大小范围广泛。单个 SPIRE 服务器可以容纳多个代理和工作负载注册条目。一个规模大小的考虑是，由于涉及到管理和发放与这些条目相对应的身份所涉及的操作数量，SPIRE 服务器实例的内存和 CPU 消耗往往与部署中的工作负载注册条目数量成比例增长。单个 SPIRE 服务器实例也代表了一个单点故障。

为了支持给定部署中更多的代理和工作负载（数以万计或数十万个节点），可以水平扩展 SPIRE 服务器的数量。有了多个服务器，SPIRE 服务器执行的计算工作将在所有 SPIRE 服务器实例之间分布。除了额外的容量之外，使用多个 SPIRE 服务器实例还可以消除单点故障，实现高可用性。

高可用性模式下的 SPIRE 服务器

要水平扩展 SPIRE 服务器，无论是出于高可用性还是负载分配目的，都要配置所有属于同一信任域的服务器以读写相同的共享数据存储。

数据存储是 SPIRE 服务器持久保存动态配置信息的地方，例如注册条目和身份映射策略。SQLite 已捆绑到 SPIRE 服务器中，它是默认的数据存储。支持一些兼容的 SQL 数据库，以及一个用于使用 Kubernetes CRD 的 Kubernetes 插件。在水平扩展 SPIRE 服务器时，请选择符合你要求的数据存储，并配置所有 SPIRE 服务器以使用所选的数据存储。有关详细信息，请参阅 数据存储插件配置参考 。

在高可用性模式下，每个服务器都维护自己的证书颁发机构，可以是自签名证书，也可以是从共享根证书颁发机构获取的中间证书（即在配置了上游机构时）。

选择 SPIRE 部署拓扑

有三种主要的 SPIRE 部署拓扑：

• 单一信任域
• 嵌套 SPIRE
• 联合 SPIRE

诸如管理域边界、工作负载数量、可用性要求、云供应商数量和身份验证要求等因素将决定你环境中的适当拓扑，如下所述。

单一信任域

单一信任域最适合个体环境或在管理域内具有相似特征的环境。创建一个单一的主导信任域的主要动机是从单个证书颁发机构中发放身份，因为这会减少在不同部署中管理的 SPIRE 服务器数量。

然而，当将单个 SPIRE 信任域部署以跨越地理区域、平台和云提供商环境时，在跨越地理位置或跨越云提供商边界的多个地方管理共享数据存储会带来一定的复杂性。在这些情况下，当部署扩展以覆盖多个环境时，解决在单一信任域上使用共享数据存储的问题的方法是在嵌套拓扑中配置 SPIRE 服务器。

嵌套 SPIRE

嵌套 SPIRE 允许 SPIRE 服务器被“链接”在一起，所有服务器仍然发放属于同一信任域的身份，这意味着在同一信任域中识别的所有工作负载都会获得可以与信任域的根密钥进行验证的身份文档。

嵌套拓扑通过在每个下游 SPIRE 服务器与“链接”的 SPIRE 代理共存来工作。下游 SPIRE 服务器通过 Workload API 获取凭据，然后使用这些凭据直接与上游 SPIRE 服务器进行身份验证以获取中间 CA。

一个有助于理解嵌套拓扑功能的心理模型是将顶级 SPIRE 服务器想象成是一个全局服务器（或一组用于高可用性的服务器），而下游 SPIRE 服务器是区域或集群级别的服务器。

在此配置中，顶层 SPIRE 服务器保存根证书/密钥，而下游服务器请求中间签名证书，用作下游服务器的 X.509 签名授权机构。这提供了弹性，因为顶层可能会崩溃，中间服务器将继续运行。

嵌套拓扑非常适用于多云部署。由于能够混合匹配节点证明者，下游服务器可以驻留在不同云提供商环境中，为不同云提供商环境中的工作负载和代理提供身份。

作为为了实现高可用性和负载平衡而将 SPIRE 服务器水平扩展的补充，嵌套拓扑可以用作分隔故障域的约束策略。

联合 SPIRE

部署可能需要多个信任根：也许因为一个组织有不同的组织部门，各自有不同的管理员，或者因为它们有单独的临时和生产环境，需要偶尔进行通信。

另一个用例是在组织之间实现 SPIFFE 互操作性，例如在云提供商和其客户之间。

这些多信任域和互操作性用例都需要一种明确定义的、可互操作的方法，使一个信任域中的工作负载能够对另一个信任域中的工作负载进行身份验证。首先通过验证各自的束终点来建立不同信任域之间的信任，然后通过经过身份验证的端点检索外部信任域束。

有关如何实现这一点的更多细节，请参阅以下 SPIFFE 规范，其中描述了这种机制：SPIFFE 信任域和束

有关配置联合 SPIRE 的教程，请参阅：联合 SPIRE 教程

与外部系统的交互

与 SPIFFE 兼容的系统联合

SPIFFE 身份颁发者可以与其他暴露 SPIFFE 联合 API 实现的 SPIFFE 身份颁发者联合，使联合域中的工作负载能够安全地进行身份验证和通信。与在 SPIRE 部署之间建立联合一样，SPIFFE 联合用于在 SPIFFE 兼容系统之间启用联合，比如在一个 Istio 服务网格和另一个 Istio 服务网格之间运行的 Istio 服务网格。

例如，在当前的 Istio 中，服务网格上的所有应用程序都位于同一个信任域中，因此共享一个共同的信任根。可能会有不止一个服务网格，或者在服务网格中通信到需要进行身份验证的外部服务。使用联合功能可以使得 SPIFFE 兼容的系统，比如多个 Istio 服务网格，能够为安全的跨网格和脱网通信建立信任。

与 OIDC 提供者系统的联合

SPIRE 具有一个特性，可以代表已识别的工作负载对远程系统进行编程身份验证，例如与支持 OIDC 联合的公共云提供商服务和密钥存储进行交互。例如，在亚马逊网络服务的情况下，一个经过 SPIRE 认证的工作负载可以对接 AWS S3 存储桶、AWS RDS 实例或 AWS CodePipeline 进行身份验证和通信。

SPIRE OIDC 发现提供者使用 ACME 协议检索 WebPKI 证书，用于保护一个端点，该端点提供 OIDC 兼容的 JWKS 束和标准 OIDC 发现文档。然后需要配置远程 OIDC 认证服务以定位该端点并确定 WebPKI 服务。一旦完成此配置，可以设置远程系统的 IAM 策略和角色以映射到特定的 SPIFFE ID。工作负载随后将通过发送 JWT-SVID 与 OIDC 认证系统通信。然后，目标系统从预定义的 URI 获取 JWKS，该 URI 由 OIDC 发现提供者提供。目标系统使用 JWKS 文件验证 JWT-SVID，如果 JWT-SVID 中包含的 SPIFFE ID 被授权访问所请求的资源，则服务请求。然后，工作负载就能够访问外部远程服务，而无需拥有由其提供的任何凭据。

有关 OIDC 发现提供者的配置参考，请参阅：OIDC 发现提供者配置参考

有关在 Amazon Web Services 配置 OIDC 联合的详细教程，请参阅：配置 OIDC 到 Amazon Web Services

部署规模考虑

在为 SPIRE 部署调整大小以实现最佳性能时，需要考虑的因素包括但不限于以下内容：

• SVID 和根证书的生存时间
• 每个节点的工作负载数量和分布
• 大量 JWT-SVID 的使用（因为 JWT 需要根据需要进行签名，而不像 x509 那样预先存储）
• 注册更改的频率
• 在 SPIRE 服务器节点上运行的其他进程
• 基础架构环境的“形状”和“大小”

特别要注意对数据存储的设计和规划。请注意，数据存储的性能在上述列表中没有得到解决，并且可能会限制 SPIRE 的性能。由于每个代理同步（每 5 秒一次）都会进行授权检查，因此数据存储通常是性能瓶颈。在嵌套拓扑中，由于嵌套拓扑中的每个 SPIRE 服务器集群都有自己的数据存储，因此可以降低此成本。

下表旨在提供关于在 SPIRE 部署中调整 SPIRE 服务器大小的参考信息。这些参考数字基于测试环境。它们仅作为数量级指南，不代表任何特定用户环境的性能保证。网络带宽和数据库查询信息未包含在内。此外，所显示的工作负载和代理数量不代表在理论上可能的 SPIRE 部署规模。