开始前的准备

本章旨在让你为上线 SPIFFE/SPIRE 时需要做出的许多决定做好准备。

准备人力

如果你读了前面的章节，你一定很想开始使用 SPIRE，以一种可以在许多不同类型的系统和所有组织的服务中利用的方式管理身份。然而，在你开始之前，你需要考虑，部署 SPIRE 是一个重大的基础设施变化，有可能影响到许多不同的系统。本章是关于如何开始规划 SPIRE 的部署：获得认同，以不中断的方式启用 SPIRE 支持，然后利用它来实施新的安全控制。

组建团队并确定其他利益相关者

要部署 SPIRE，你需要确定来自安全、软件开发和 DevOps 团队的利益相关者。谁来维护 SPIRE 服务器本身？谁来部署代理？谁来编写注册条目？谁将把 SPIFFE 功能集成到应用程序中？它将如何影响现有的 CI/CD 管道？如果发生了服务中断，谁来修复它？性能要求和服务水平目标是什么？

在这本书中，以及许多公开的博客文章和会议演讲中，都有一些成功部署 SPIRE 的组织的例子，既可以作为一种模式，也可以作为向同事宣传 SPIRE 的有用材料。

说明你的情况并获得支持

SPIRE 跨越了几个不同的传统信息技术孤岛，因此，期望看到你的 DevOps 团队、软件开发团队和安全团队之间有更多的跨组织合作。重要的是，他们要一起工作，以确保成功和无缝部署。考虑到这些团队中的每一个都有不同的需求和优先事项，需要解决这些问题以获得他们的支持。

在规划 SPIRE 部署时，你需要了解哪些成果对你的企业最重要，并将这些成果作为项目的驱动力和你将提供的解决方案的价值。每个团队都需要看到 SPIRE 对自己以及对整个企业的好处。本书第 2 章 “收益” 中描述了 SPIRE 部署的许多好处，在本节中，我们将把其中一些好处提炼成令人信服的论据。

对安全团队有说服力的论点

减少安全团队的工作量是部署 SPIRE 的一个非常有说服力的案例：他们可以专注于设计正确的注册条目，以确保每个服务获得正确的身份，而不是部署临时的安全解决方案，以及手动管理数百或数千个证书。

一个更长期的好处是，SPIRE 可以提高组织的整体安全态势，因为 SPIRE 没有容易被盗或误用的凭证。与盗用或歪曲凭证有关的大量攻击，以及敏感数据的暴露，都得到了缓解。有可能向外部审计师证明，正确的服务正在相互安全地进行通信，没有意外疏忽的可能。即使外部人员可以破坏一个服务，他们对其他服务发起攻击的能力也是有限的。

对软件开发团队有说服力的论点

对于应用程序开发团队来说，他们能够通过不等待工单或手动工作流程来提供证书而加快行动，这是最有说服力的案例。如果他们目前在代码旁边手动部署秘密，并被安全团队谈话，他们不再需要忍受这些。他们也不需要在秘密存储中管理秘密。

一个次要的好处是，软件组件可能能够以它们以前无法安全进行的方式直接进行通信。如果云服务不能访问一个关键的数据库或基本的云服务，因为没有办法安全地做到这一点，那么就有可能使用 SPIFFE 身份来创建一个安全连接，为你的团队提供新的架构潜力。

对 DevOps 团队有说服力的论点

部署 SPIRE 的最大收益是针对 DevOps 团队。如果每个服务都有自己的安全身份，那么服务就可以部署在任何地方 —— 在任何内部数据中心、云供应商或一个云供应商中的区域。这种新的灵活性允许降低成本，提高可扩展性，并改善可靠性，因为部署决策可以独立于安全要求。

对 DevOps 团队来说，另一个关键的好处是，每个服务的传入请求都被贴上 SPIFFE ID 的标签，这可以被记录、测量，并报告给监控系统。这对拥有数百或数千项服务的大型组织的性能管理是非常有帮助的。

创建一个计划

规划 SPIRE 部署的第一个目标是确定是否每项服务都需要被 SPIFFE 感知，或者非 SPIFFE 服务的 “孤岛” 是否仍然可以满足要求。将每项服务都转移到 SPIFFE 是最直接的选择，但要一下子全部实施可能是个挑战，特别是在非常大的组织中。

岛屿和桥梁的规划

有些环境很复杂，要么有多个组织，要么是传统和新开发的结合。在这种情况下，人们往往希望只让环境的一个子集启用 SPIFFE。需要考虑两种选择，这取决于系统之间的整合程度和它们之间的复杂性。让我们来看看这两种架构，我们称之为 “独立岛” 和“桥接岛”。

每个岛被认为是它自己的信任域，在每个岛上有工作负载或“居民”。

独立岛

独立岛模式允许各个信任域相互独立运行。这通常是最简单的选择，因为每个岛可以以对该岛有意义的方式运行 SPIRE。

桥接岛

桥接岛模式允许非 SPIFFE 岛上的非 SPIFFE 服务与网关对话。然后，网关将请求转发给支持 SPIFFE 的岛上的居民，我们称他们为 Zero。从 Zero 的角度来看，网关发出了请求。Zero 和他在支持 SPIFFE 的岛上的朋友可以向网关进行认证，并向非 SPIFFE 岛上的服务发送消息。

在桥接岛架构下，网关是在未启用 SPIFFE 的岛上创建的。这些非 SPIFFE 岛可能不容易采用 SPIFFE 架构，原因有很多：可能有遗留软件，不能轻易修改或更新；岛屿可能使用自己的识别生态系统，如 Kerberos 或 SPIFFE 与其他技术比较一章中描述的其他选项之一；或者系统可能在不太适合现有 SPIFFE 解决方案（如 SPIRE）模式的技术上运行工作负载。

在这些情况下，使用网关服务在 SPIFFE 世界和非 SPIFFE 岛之间架起连接的桥梁可能是有用的。当支持 SPIFFE 的工作负载想要与非 SPIFFE 岛的工作负载对话时，它与网关建立一个经过认证的连接，然后与目标工作负载建立一个连接。这个与目标工作负载的连接可能是未经认证的，或者使用该岛的非 SPIFFE 身份解决方案。同样，当非 SPIFFE 岛的工作负载想要连接到 SPIFFE 启用的工作负载时，非 SPIFFE 工作负载会连接到网关，然后创建一个 SPIFFE 认证的连接到目标 SPIFFE 启用的工作负载。

在这种情况下，发生在网关和启用 SPIFFE 的工作负载之间的认证在网关处被终止。这意味着支持 SPIFFE 的工作负载可以验证它是在与适当的网关对话，但不能验证它是在与网关另一端的正确工作负载对话。同样，目标工作负载只知道网关服务向它发送了一个请求，但却失去了原 SPIFFE 启用的工作负载的验证背景。这种模式允许这些复杂的组织开始采用 SPIFFE，而不必一下子转换。

在请求和工作流通过非 SPIFFE 岛的情况下，利用 JWT-SVID 进行跨请求的传播会很有用。你可以使用 X509-SVID 来签署文件（如 HTTP 消息请求签署），而不是只使用服务间的相互认证的 TLS，这样整个消息的真实性就可以被另一边支持 SPIFFE 的工作负载所验证。这对已知安全属性较弱的岛屿特别有用，因为它提供了对通过中间生态系统的消息没有被操纵的信心。

文档和监控工具

在准备开始上线时，重要的是要对服务进行检测，使指标和流量日志以一种方式暴露出来。

• 监督上线的人知道哪些（以及有多少）服务是支持 SPIFFE 的，哪些（以及有多少）不是。
• 客户端作者知道他们调用的哪些服务是支持 SPIFFE 的，哪些不是。
• 服务所有者知道他们的哪些客户端以及有多少客户端在调用支持 SPIFFE 的端点，哪些在调用传统端点。

重要的是，要为客户端和服务器实施者创建参考文件，预测你将收到的支持请求的种类，从而为上线做准备。

同样重要的是，创建工具来协助完成常见的调试和故障排除任务。回顾 SPIFFE 和 SPIRE 的收益，将 SPIFFE 引入你的组织应该赋予开发人员权力并消除路障。给利益相关者留下的印象是你在增加工作或制造摩擦，最终会减缓或停止更广泛的采用。为了减少这种情况，并确保文档和工具涵盖适当的主题，我们建议采取以下准备步骤。

了解性能影响

应将性能影响作为部署规划的一部分加以考虑。

作为上线准备的一部分，你应该检查一系列工作负载的基准，这些工作负载代表了你的组织在生产中运行的各种应用。这可以确保你至少意识到，并希望能准备好解决在推广过程中可能出现的任何性能问题。

TLS 性能

在许多组织中，开发人员和运维团队提出的第一个担忧是，在服务之间建立相互的 TLS 连接会太慢。在现代硬件上，通过现代的 TLS 实现，TLS 的性能影响是最小的。

“在我们的生产前端机器上，SSL/TLS 占 CPU 负载的比例不到 1%，每个连接占内存的比例不到 10KB，网络开销不到 2%。许多人认为，SSL/TLS 需要大量的 CPU 时间，我们希望前面的数字能帮助消除这种想法。"——Adam Langley， Google，Overlocking SSL，2010 年

“我们已经使用硬件和软件负载均衡器大规模地部署了 TLS。我们发现，在商用 CPU 上运行的基于软件的现代 TLS 实现，其速度足以处理繁重的 HTTPS 追踪负载，而不需要求助于专用加密硬件。"——Doug Beaver，Facebook，HTTP2 Expression of Interest，2012 年

一般来说，性能影响取决于多种因素，包括网络拓扑结构、API 网关、L4-L7 防火墙和其他许多因素。此外，你所使用的协议及其实现以及证书和密钥大小也可能影响性能，所以这是一个相当广泛的话题。

下表提供了与 TCP 相比两个不同阶段的开销数据，特别是握手和数据传输阶段的数据。

向 SPIFFE 和 SPIRE 转变

关于组织如何对变化作出反应、影响和处理的研究有着丰富的历史。关于公众和组织对新技术的接受和采用，也有许多有趣的研究。对这些主题进行真正的公正研究超出了本书的范围，但如果我们不提及这些主题，那就是我们的失职，因为它们与 SPIFFE 的成功推广相关。

令人信服的变化发生

有几种方法可以说服他人，在你的组织内必须发生变化。下面的清单概述了你可以通过 SPIFFE 和 SPIRE 追求这种变革的方法。

• 提升感知价值：展示 SPIFFE 对工作绩效的积极影响是关键，让人们相信它对他们有实质帮助。
• 简化易用性：为了让 SPIFFE 易于使用，必须投入大量精力来提升开发者和运维人员的用户体验。
• 同行影响力：重视受尊敬人士对于 SPIFFE 的看法以及他们是否采用它，这将在组织内积累政治资本。说服关键人物通常比说服所有人更为重要。
• 提升形象：采用 SPIFFE 将对个人在组织中的地位产生显著影响。
• 自愿采用：SPIFFE 潜在用户的自愿采用程度受公司文化和个性影响。在面对“被迫”采用者和拒绝采用者时，请务必牢记这一点。

采用者角色

采用者与技术曲线相对应，可以帮助设定对如何向 SPIFFE 和 SPIRE 转变的预期。在此，我们列出了技术曲线中所涉及的采用者，并增加了两个你可能会遇到的采用者。

关于技术采用曲线中的采用者的更多信息可以在本书之外找到。

• 创新者：把你自己看作是组织中的创新者，因为你采取了这些步骤来阅读本书，走到这一步，并决定继续前进。你基本上是在开拓将 SPIFFE 和 SPIRE 添加到你的架构中的进程，你需要帮助！你需要一个 " 白手套“级别的支持和和帮助，所以一定要从低垂的果实和先导类别（下文有介绍）中挑选志愿者，并与他们保持良好的关系。
• 早期采用者：重要的是要从给予创新者的“白手套 “手把手支持水平中吸取经验教训，并将这些经验提炼成易于获取和理解的文档、有用的工具和可扩展的支持渠道。可能需要做大量的工作来实现 SPIFFE 的” 先驱者和推动者”（在本章后面会详细介绍），以便开发者能够解除障碍，然后能够实现 SPIFFE 的服务和客户端。
• 早期和晚期大众：当你进入早期多数服务的时候，SPIFFE 的启用过程已经是一台运转良好的机器了。所有常用的使能器，如 CI/CD、工作流引擎、编排器、容器平台和服务网格，都应该启用 SPIFFE，以确保应用开发者在整个应用生命周期中得到支持，无论应用如何运行。
• 落后者：由于团队文化、个人性格以及监管或合规要求，你的组织可能有保守的落后者。重要的是，不要对服务所有者为什么会落入这个类别下结论，而是要调查根本原因并适当解决。
• “被迫” 转型：最后一个采用 SPIFFE 的服务的客户可能会感到被迫转型。重要的是要为被迫转型者做好准备，确保他们采用 SPIFFE 的经验是积极的。
• 滞留者：他们会出现，所以要让他们容易接受并受到激励。突出其他人目前正在享受生产力平台的例子。你应该期望提供额外的支持和帮助，因为在这个过程中会有很多人犹豫不决。

时机选择的考虑因素

在你选择谁来做的时候，在你的组织中保持最大的兼容性是至关重要的考虑。服务应保持其现有的 API 接口和端口，并在新的端口上引入其启用 SPIFFE 的 API。这样可以实现平稳过渡，并在需要时方便回滚。有许多来自其他服务团队客户端的服务团队应该期望在很长一段时间内（>6 个月）维护和支持这两个端点。

一旦一项服务的所有客户端都启用了 SPIFFE，并且不再使用非 SPIFFE 的 API，那么非 SPIFFE 的 API 就可以被关闭。

要注意不要过早地关闭遗留的端点。要特别注意批处理作业、计划任务和其他类型的不经常或不规则的调用模式。你不希望成为导致季度末或财务年度末对账工作失败的人。

如果你的环境太大或者太复杂，无法一下子完成，那么在选择服务启用 SPIFFE 的顺序时，一定要深思熟虑。从大石头、最低的果实和 " 先驱者和推动者“的角度来考虑可能会有帮助，以加速采用。

大石头

大石头是指拥有最独特客户端的服务，以及与最多独特服务端连接的客户端。尽早处理大石头可能对加快采用速度很有诱惑力，但可能会导致得不偿失，造成问题，并使其他人不愿采用 SPIFFE。

看一下上面的调用图，可以通过连接最多的节点来识别大石头。它们可能是被许多客户端调用的关键服务，如 Service 0；它们可能是调用许多服务端的客户端，如 Service 4。大石头还可能包括既是客户端又是服务端的服务，如 Service 7。应对这些服务的迁移，既有好处，也有风险。

效益

• 有吸引力的选择
• 潜在的快速采用
• 影响广泛的好处
• 激励他人采用

风险和挑战

• 长期维护 2 个终端（传统的和支持 SPIFFE 的）
• 只有在所有客户端都采用了 SPIFFE 之后，才会关闭传统的端点
• 增加维护成本
• 增加了复杂性
• 扩展了组织能力
• 强制采用
• 不满的团队
• 惊喜的是，角落里有一只乌龟！

低垂的果实

最低矮的果实是拥有一至几个客户端的服务，或与一个或几个服务连接的客户端。这些通常是最容易指导过渡的，并且是理想的第一批采用者。

看一下上面的同一张图，低垂的果实是连接很少的节点。这些服务可能是单一的、其他服务的客户端，如 Service 2。低垂的果实也可能包括只有一个客户端的服务，比如 Service 8。在选择首先迁移哪些连接很少的服务时，明智的做法是选择那些最容易维持双端点的服务（传统的和 SPIFFE），或者那些必须在最短的时间内维持双堆栈的服务。

效益

• 如果出了问题，风险更小
• 由于需要较少的协调和规划，因此更容易从传统的方式完全转换到 SPIFFE 上
• 良好做法和学习机会

风险和挑战

• 推广工作可能被认为是缓慢的
• 可能没有足够的可见性或影响力来激发关键服务所有者的采用

加速采用

一些先导因素和推动因素可以促进 SPIFFE 在复杂和异构环境中的采用。它们中的每一个都有一系列不同的好处和挑战需要考虑。上面的考虑因素也适用于此；选择影响最广泛的系统，在确定所有非 SPIFFE 的消费者都已转换之前，不要转而使用非 SPIFFE 功能。

先行者包括帮助他人采用 SPIFFE 的工具和服务（如 CI/CD 和工作流引擎）。开发和运维工具应该提供给第一批采用者（创新者），并随着早期采用者的加入而反复改进。我们的目标是使工具和服务在早期大多数人加入的时候达到成熟。如果没有足够的前期投资，后期的大多数人和落伍者将陷入困境。

开发者工具

拥有有助于提高生产力的工具是成功推广 SPIFFE 的关键。收集一份你的组织在应用生命周期中使用的现有工具清单，从开发到运维再到报废，并考虑哪些现有工具应该支持 SPIFFE，是否需要建立、购买或部署新的工具。花在创建、整合和改进工具上的时间和精力往往会产生倍增效应，为其他人节省时间和精力，从而帮助促进更顺利的过渡。

值得注意的是，不应该孤立地建立或购买工具，而应该与他们的目标用户协商，最好是以渐进和迭代的方式。正确地做到这一点可能需要时间。

选择什么时候一个工具对第一批和早期采用者来说足够好是一个判断。在极少数情况下，工具的第一次迭代对早期和后期的大多数人来说是足够好的。

持续集成和部署系统

在 CI/CD 工具中实施 SPIFFE 会对组织中其他服务部门采用这种 SPIFFE 产生很大的影响，因为大多数团队都会与 CI/CD 系统定期互动。然而，反过来说，这意味着要让 CI/CD 系统的所有消费者都能意识到 SPIFFE 是一项庞大的任务，所以可能需要很长的时间来关闭所有非 SPIFFE 的集成。

容器编排器

如果你的组织已经在使用容器编排器，如 Kubernetes，那么你就成功了一半！你的组织已经在使用容器编排器。编排器使你的工作负载很容易通过 SPIFFE 感知代理前置，这样你的开发者就不需要再费心了。

服务网格

大型微服务服务网格架构作为 SPIFFE 部署的推动者尤其重要，因为在服务网格中引入 SPIFFE 支持是一种推出广泛支持的好方法，而不必让开发团队参与进来。

服务网格的相关性也伴随着一些风险和挑战。你可以想象，破坏服务网格可能会在一个环境中产生广泛的影响，并可能以灾难性的失败告终。

规划 SPIRE 行动

日复一日地运行 SPIRE

建议负责管理和支持 SPIRE 基础设施的团队尽可能早地参与。根据你的组织结构，很可能是你的安全或平台团队将负责整个生命周期的工作。

另一个需要考虑的方面是你如何分割涉及任何会影响系统安全、性能和可用性的改变的操作。在改变任何与你的 PKI、HSM、密钥轮换和相关操作有关的东西时，可能需要更严格的控制和门槛。你可能已经有一个围绕它的变更管理过程，如果没有，这是一个开始实施它的绝佳时机。

你的团队需要为不同的故障场景创建 Runbook，并对其进行测试，以了解该怎么做，需要观察哪些基本指标，并创建监控和警报。你可能已经知道你将使用什么监控和警报系统，但了解 SPIRE 服务器和代理提供的遥测数据和指标，以及这些数据意味着什么，将有助于你的团队避免停机时间。

测试复原力

故障注入练习帮助操作人员分析系统在某些故障条件下的表现。你可能对你的系统将如何基于架构做出反应有某些假设。尽管如此，在 SPIRE 部署中仍有多个潜在的故障点值得触发，以测试你的假设，并可作为运营团队的良好实践，以确保他们有所有的警报和 Runbook。

我们整理了一个清单，其中包括一些你想在你的故障测试程序中包括的情景。这不是一个完整的指南，只是为你的特定环境和部署模式建立检查表的一个起点。最好是用不同的停机时间来执行所有这些测试：短于配置的 TTL 的一半和更长的时间。

1. 如果 SPIRE 的部署是使用一个单一的数据库实例，请关闭该数据库。
2. 如果 SPIRE 部署在一个集群中使用一个数据库，有一个写副本和多个读副本，请关闭写实例。
3. 模拟数据库丢失，测试数据恢复。如果你不能恢复数据或只能从一个月前的数据中恢复，怎么办？
4. 在 HA 部署中关闭几台 SPIRE 服务器。
5. 在 HA 部署中关闭负载均衡器。
6. 在代理被证明后关闭它，或完全模拟 SPIRE 服务器丢失。
7. 如果使用上游授权，模拟上游授权失败。
8. 模拟根和中间 CA 的破坏、轮换和撤销。

定义哪些指标在每个测试场景中是最有用的，记录这些数值的预期健康和危险范围，并随着时间的推移进行测量。

这些场景应该被很好地记录下来，预期的输出被很好地定义，然后通过自动和定期运行的自动化测试来实现。

日志

像所有系统一样，日志是 SPIRE 的一个重要组成部分。然而，SPIRE 产生的日志也可作为审计和安全事件的证据。包含身份签发信息以及可观察到的证明细节，可以用来证明某些工作负载和服务的状态。由于日志可以被视为证据，因此在组建日志解决方案时，你可能希望注意到以下几个注意事项。

• 记录的保留应符合你的组织的法律要求
• 日志系统在接纳日志和存储方面都应具有高可用性
• 日志应该是防篡改的，必须能够提供证据
• 记录系统应该能够提供一个监管链

监控

除了通常的 SPIRE 组件的健康状况以确保系统正常运行外，你应该设置对服务器、代理和信任包的配置的监控，以检测未经授权的更改，因为这些组件是系统安全的基础。此外，还可以对身份的发放以及服务器和代理之间的通信进行监控，以发现异常情况。然而，根据系统中发布的身份信息量，你可能希望重新考虑监控的范围。

SPIRE 通过遥测技术为指标报告提供灵活的支持，允许使用多个收集器收集指标。目前支持的指标收集器有 Prometheus、Statsd、DogStatsd 和 M3。在服务器和代理中都可以同时配置多个采集器。

SPIRE 上有许多指标，其记录涵盖了所有的 API 和功能。

• 服务器
  • 管理 API 操作
  • 每个 API 的 DB 操作
  • SVID 发行的 API 操作
  • 轮换和秘钥管理
• 代理
  • 与服务器的交互
  • SVID 轮换和缓存维护
  • 工作负载证明