原文：Scaling SPIRE
SPIRE 的容量是有限的，随着工作负载强度的不同，需要有不同的规模。一套 SPIRE 中的 Server 部分，可能由一或多个共享数据存储的 SPIRE Server 组成；还可以是同一信任域的多个 SPIRE Server；至少有一个 SPIRE Agent，当然，多数时候是多个 Agent。
部署规模和负载规模相关。单个 SPIRE Server 能够承载一定数量的 Agent 和注册项。SPIRE Server 负责管理和签发注册项的身份，因此它的内存和 CPU 消耗是随着负载注册条目的数量线性增长的。单一的 SPIRE Server 部署还可能导致单点失败。
SPIRE Server 可以用水平扩展的方式支持大量的 Agent 和工作负载。多个 Server 的情况下，运算任务会分布到多个 SPIRE Server 实例之中。除了算力增加，多实例部署也避免了单点失败的风险。
高可用模式的 SPIRE Server
要用水平扩展的方式来实现高可用和分布式计算，只需要让所有服务器共享同一个信任域和数据存储就可以了。
SPIRE Server 会把注册项和身份映射策略等动态配置信息进行持久化，缺省情况下会使用内置的 SQLite，同时可以使用多种 SQL 数据库进行存储，还可以通过插件将数据保存在 Kubernetes 的 CRD 之中。所以要对 SPIRE Server 进行水平扩展之前，就要选择满足需求的数据存储方式。这方面的内容可以参考数据存储插件文档。
高可用模式里，每个服务器都管理着自己的 CA，这个 CA 可能是自签发，也可能是一个共享的上游根 CA 所签发的中间证书。
选择 SPIRE 部署拓扑
SPIRE 有三种部署拓扑：
管理域边界、工作负载数量、高可用需求、供应商数量以及认证需求都是部署方案的决策输入项。
单信任域
单信任域拓扑适用于独立环境或者一个管理域内的多个环境共享。单信任域的最大好处就是从单一 CA 中签发身份证书，能有效降低 SPIRE Server 的部署管理的复杂度。
然而要跨越 Region、平台或者供应商的话，单信任域就面临容灾、分布等需求的挑战了。这种情况下，嵌套部署就比较有优势了。
嵌套 SPIRE
SPIRE 的嵌套部署呈现了一种链式结构，虽然是多个 Server，但是签发的是同一个信任域的身份，这样所有工作负载的身份都处在同一个信任域里，能够用该信任域的根密钥进行校验。
嵌套拓扑中，下游 SPIRE Server 和上游的 SPIRE Agent 共同部署。下游 SPIRE Server 通过使用 Workload API 获取凭据，这些凭据会用于和上游 SPIRE Server 进行通信获取中间 CA。
一种便于理解嵌套拓扑的思路：上游 SPIRE 服务器是一个（或者是一组高可用部署的）全局服务器，下游 Server 是 Region 或者集群级的。
在这种情况下，顶层 SPIRE Server 掌管着根证书/密钥，下游服务器会向上层请求中间证书，用于下游 CA。这样即使是顶层服务宕机，中间服务器还能继续运作，一定程度上提高了可用性。
嵌套逻辑也能用于多云环境。对 Node Attestor 进行匹配之后，下游服务器能够为不同的云供应商环境中的工作负载和 Agent 提供证明。
水平扩展 SPIRE Server，达到高可用和负载均衡的目的，作为互补，嵌套拓扑可以作为一种遏制策略来对故障域进行分割。
SPIRE 联邦
有时会需要多个信任根共存：有的组织会有不同的分隔和不同的管理，或者多个环境之间偶尔进行通信。
还有一种用例就是在组织之间（例如云供应商和客户之间）进行 SPIFFE 的互操作。
这种多信任域和互操作需要良好定义的互操作方法，让一个信任域的工作负载能够认证另一个信任域的工作负载。互信的技术细节可以参考 https://github.com/spiffe/spiffe/blob/main/standards/SPIFFE_Trust_Domain_and_Bundle.md#5-spiffe-bundle-endpoint，具体操作可以阅读 https://github.com/spiffe/spire-tutorials/tree/main/docker-compose/federation
和外部系统的互动
SPIFFE 兼容系统
SPIFFE 身份能够和其它提供了 SPIFFE 联邦接口的系统对接，在联邦中进行安全的认证和通信。和 SPIRE 联邦类似，可以在 SPIFFE 兼容的系统之间（例如 Istio 和 SPIRE，或者两个 Istio 之间）建立联邦。
例如目前的 Istio 中所有的应用都在同一个信任域里，或者说是共享一个信任根。可能存在多个服务网格，或者服务网格中的应用需要和外部的服务进行受保护的通信。联邦 SPIFFE 就可以用来够完成网格之间或者网格内外的互信关系。
OIDC-Provider
针对公有云之类的 OIDC 兼容的提供商，SPIRE 能够代表通过认证的工作负载和远端系统进行可编程的认证。例如在 AWS 上，SPIRE 认证的工作负载能够和 AWS S3、RDS 或者 AWS CodePipeline 进行通信。
SPIR OIDC Discovery Provider 用 ACME 协议获取 Web PKI 证书，这个证书用于一个端点的安全，这个端点会提供 OIDC 兼容的 JWKS 包以及标准的 OIDC 发现文档。远程 OIDC 认证服务进行配置之后，能够定位到这一端点，并对 WebPKI 服务进行验证。配置生效后，远端系统的 IAM 策略和角色可以和 SPIFFE ID 进行映射。工作负载可以使用 JWT-SVID 访问 OIDC 认证的系统。被访问系统从预定义的 OIDC 发现服务 URI 中获取 JWKS，如果 JWT-SVID 中包含的 SPIFEE ID 是被允许访问该资源的，就放行。这样一来，工作负载就能访问外部远程服务，无需额外处理认证问题了。
OIDC 发现服务配置：https://github.com/spiffe/spire/tree/main/support/oidc-discovery-provider
AWS OIDC 联邦指南：https://spiffe.io/spire/try/oidc-federation-aws/
部署规模评估
在评估 SPIRE 部署规模时，需要考虑如下因素：
SVID 和根证书的 TTL
每节点的工作负载数量
JWT-SVID 的用量（JWT 必须按需签署，不像 x509 是预生成的）
注册项的变更频率
SPIRE 服务所在节点上的其它进程
底层基础设施环境的形态和容量
数据存储的设计规划非常重要。上表没有提到数据存储问题，但它会对 SPIRE 性能造成潜在限制。每次 Agent（每 5 秒钟）的认证同步，都是一个昂贵的操作，数据存储可能成为性能瓶颈。嵌套拓扑中每个 SPIRE 服务器都存储自己的数据，因此可以降低这种成本。
下表尝试呈现一个 SPIRE 的规格指导。数据来自于一个测试环境，所以无法对任何用户的实际环境提供保障，只能在数量级上给出一个参考。网络带宽和数据性能没有包含在内。另外工作负载和 Agent 数量也不代表 SPIRE 规模的理论上限。
| Number of Workloads | 10 Agents | 100 Agents | 1000 Agents | 5000 Agents |
| 10 Workloads | 2 Server Units with 1 CPU core, 1GB RAM | 2 Server Units with 2 CPU cores, 2GB RAM | 2 Server Units with 4 CPU cores, 4GB RAM | 2 Server Units with 8 CPU cores, 8 GB RAM |
| 100 Workloads | 2 Server Units with 2 CPU cores, 2GB RAM | 2 Server Units with 2 CPU cores, 2GB RAM | 2 Server Units with 8 CPU cores, 8 GB RAM | 2 Server Units with 16 CPU cores, 16 GB RAM |
| 1,000 Workloads | 2 Server units with 16 CPU Cores, and 8GB RAM | 2 Server units with 16 CPU Cores, and 8GB RAM | 2 Server units with 16 CPU Cores, and 8GB RAM | 4 Server units with 16 CPU Cores, and 8GB RAM |
| 10,000 Workloads | 4 Server units with 16 CPU Cores each, and 16 GB RAM | 4 Server units with 16 CPU Cores each, and 16 GB RAM | 4 Server units with 16 CPU Cores each, and 16 GB RAM | 8 Server units with 16 CPU Cores each, and 16 GB RAM |
