本章包括五个业界案例，他们是现实世界中部署了 SPIFFE 和 SPIRE 的企业的工程师。
Uber：用加密身份确保下一代和传统基础设施的安全
Ryan Turner，软件工程师，Uber
在过去十年中，Uber 已经成为爆炸性增长的典型代表。随着软件服务的数量和我们运营的地理规模的增长，复杂性和风险也在增加。为了满足不断增长的需求，我们开始建立我们的下一代基础设施平台。同时，几年前，我们看到开源项目 SPIFFE 和 SPIRE 的一些早期动力。
我们立即看到了 SPIFFE 所能带来的价值，使我们能够加强我们的下一代基础设施安全态势。我们在 Uber 上线了 SPIRE，现在正使用它在各种工作负载环境中使用可加密验证的身份建立信任。我们从一些应用服务和内部服务开始，比如一个工作流引擎，它通过访问整个平台的数据，旋转多个动态工作负载来完成特定任务。SPIRE 向我们的工作负载提供 SPIFFE 身份，跨越我们的应用周期。SPIFFE 用于验证服务，帮助我们避免可能导致生产问题的错误配置。
使用 SPIRE 改造传统堆栈
SPIRE 现在是 Uber 的下一个基础设施的关键组成部分，但我们也在使用 sidecar 的方法，将认证改造成传统的基础设施。虽然 SPIFFE 和 SPIRE 通常都是在现代的云原生架构中工作，但我们可以将这些项目迅速适应我们专有的遗留堆栈。SPIRE 可以在 Uber 的下一代和传统基础设施中提供一个关键的信任桥梁，并对内部安全和开发人员的效率产生积极影响。
在我们的旅程中，SPIFFE 社区一直非常支持我们，帮助我们找到解决方案。因此，我们的工程师也积极为项目做出代码贡献。
安全、开发和审计团队正在受益于 SPIFFE
SPIFFE 使我们的安全团队对后端基础设施更有信心，对基于网络的安全控制的依赖性更低。由于我们处理的是金融数据，而且是跨地域经营，我们必须控制对金融和客户数据的访问。有了 SPIRE，我们可以为访问控制提供一个强有力的证明身份。它帮助我们满足这些要求，并在这个过程中减少审计团队的负担。
我们 Uber 的开发团队使用一致的客户端库，使用基于 SPIFFE 的身份创建 AuthZ 策略。这些项目使开发团队能够利用 X.509 和 JWT 等工作量大的身份基元，而不需要深入了解信任引导、安全引入、凭证供应或轮换等复杂主题。
Pinterest：用 SPIFFE 克服身份危机
Jeremy Krach，高级安全工程师，Pinterest
2015 年，Pinterest 出现了身份危机。该公司的基础设施正在向不同的方向发展。每个新系统都以其独特的方式解决认证 —— 身份问题。开发人员每个月都要花几个小时的时间在会议和安全审查上，以设计、建立威胁模型和实施他们的定制身份解决方案，或将他们的新服务与不同的身份模型的依赖关系整合。很明显，安全团队需要建立一个通用的基础设施，以一种通用的方式提供身份，可以在我们的异构服务中使用。
这个系统的最初草案将身份委托给机器，作为基于主机名的 X.509 证书。它被大量用于秘密管理（见 Knox），但还没有出现更广泛的采用。随着我们不断扩大规模，特别是像 Kubernetes 这样的多租户系统，我们需要更精细的身份，这些身份并不与我们基础设施中的特定主机相联系，而是与服务本身的身份相联系。进入 SPIFFE。
用 SPIFFE 将复杂的问题扁平化
SPIFFE 现在为我们的大部分基础设施提供统一的身份。我们最初从 Kubernetes 开始，因为在那个多租户环境中需求是最明确的。后来，我们将其他基础设施转移到 SPIFFE，作为其主要的身份识别形式。因此，Pinterest 的几乎每个服务都有一个标准化的名字，我们可以使用，没有晦涩的惯例或不连贯的方案。它帮助我们统一和规范了我们的身份惯例，这与其他内部项目保持一致，以确定服务属性，如服务所有权。
我们利用 SPIFFE 作为 ACL 中的身份，用于秘密管理、TLS 服务之间的相互通信，甚至是通用授权策略（通过 OPA，另一个 CNCF 项目）。Knox，Pinterest 的开源秘密管理服务，使用 SPIFFE X.509 身份文件作为支持的认证方法之一。请看我们关于 在 Knox 中添加 SPIFFE 支持的博文。
开发、安全和运维又开始和谐相处了
SPIFFE 使安全团队更容易编写授权策略。开发者的速度明显提高，因为我们的工程师不必担心自定义方案或不同的集成认证。由于我们现在有一个标准的方式来解释我们整个基础设施的身份，所以计费和所有权团队更容易确定谁拥有一项服务。有了强大的身份意识，对于记录和追踪一致性也很方便。我们对 SPIFFE 项目的未来感到兴奋，并感谢它能够帮助我们解决身份危机！。
字节跳动：为网络规模的服务提供拨号音认证
Eli Nesterov，安全工程经理，字节跳动
TikTok 背后的公司字节跳动已经在全球范围内建立和部署了大规模的互联网服务，为数百万用户提供服务。我们支持这些服务的基础设施是私有数据中心和公共云供应商的组合。我们的应用程序以数千个微服务的形式在多个 Kubernetes 集群和跨平台的专用节点上运行。
随着我们规模的扩大，我们的平台上有多种认证机制，包括 PKI、JWT 令牌、Kerberos、OAuth 和自定义框架。在这些认证机制中加入大量的编程语言，操作的复杂性和风险就更大了。对我们的安全和运维团队来说，管理这些认证方案在操作上变得复杂。在认证框架出现已知漏洞的情况下，我们无法迅速采取行动，因为每个框架都必须单独处理。在某些情况下，他们有代码级的依赖性，这使得改变变得更加困难。跨地域的审计和合规性是一个挑战，因为每个平台特定的认证方法都必须被单独审查和管理。
总体上走向基于零信任的架构，以及努力提高我们的开发人员的生产力，迫使我们为我们的服务建立一个统一的身份管理平面，以满足我们不断增长的需求。
使用 SPIRE 构建网络规模的 PKI
要建立一个能在不同的基础设施岛屿或像我们这样的平台上工作的身份系统是很难的。我们可以创建自己的，但这需要大量的努力。我们选择了 SPIRE，因为它在支持我们需要的各种平台和网络规模方面提供了规模和灵活性。由于它提供了基于标准 X.509 证书的加密身份，它可以帮助我们轻松地启用相互 TLS，在默认情况下，它符合许多合规性要求。可扩展性和开源性是另一个优点，因为我们可以很容易地将它与我们现有的控制平面和数据堆栈集成。
透明的认证简化了操作
有了 SPIRE，我们可以在我们所有的平台上部署一致的“拨号音 “认证。现在，认证和安全的负担从开发人员那里被封装起来，因此他们可以专注于业务或应用逻辑。这从整体上提高了我们的部署速度。我们也不太可能因为配置问题而出现” 生产错误 “，例如在生产中使用开发凭证。
使用 SPIRE 的标准化认证也简化了合规性和审计，因为我们有跨信任域和平台的相互 TLS。SPIRE 还允许我们在身份分配方面转向一个更半分散的模式，即身份系统是本地的，比如一个数据中心。这提高了我们的整体可用性，使我们能够很好地恢复。
有了 SPIRE，我们几乎是“面向未来 " 的，因为它可以扩展和适应，以满足我们不断增长的业务需求。
Anthem：用 SPIFFE 保护云原生医疗应用的安全
Bobby Samuel，Anthem 人工智能工程副总裁
行业内不断上升的医疗成本迫使像 Anthem 这样的组织迅速创新，重新思考我们与供应商、雇主团体和个人的互动方式。作为这一举措的一部分，我们正在开发大量的应用程序，这些应用程序将帮助我们通过安全地开放医疗数据的访问来推动成本下降。我们已经开始在 Kubernetes 等云原生技术的基础上建立配套的下一代基础设施。这个新的基础设施将推动快速创新，并吸引更广泛的组织和开发人员的生态系统。这方面的一个例子是我们的 HealthOS 平台。HealthOS 将使第三方能够建立 HealthApp 能力，以提供到前端界面，利用去识别的健康数据的海洋。
但是，在几乎每一个大型企业，特别是医疗机构，都有人试图以恶意的方式获取他们的数据。受保护的医疗信息（PHI）的售价比金融信息高得多；因此，黑客和脚本小子等恶意行为者发现医疗系统和相应的健康信息非常有利可图。随着云原生架构的采用，风险和复杂性进一步上升。由于威胁半径大大增加，而人工安全审查和流程成为云规模的抑制因素，因此发生漏洞的风险更高。
为零信任架构打下基础
我们不能依靠传统的基于参数的安全工具和流程来保护我们的下一代应用程序和基础设施。零信任是一种精细的、自动化的安全方法，对我们来说很有意义，特别是在未来，因为我们计划跨组织边界和云供应商进行操作。用户和服务的身份和认证是零信任安全模型的核心原则之一。零信任使我们能够减少对基于网络的控制的依赖，而不是对每个系统或工作负载进行认证。SPIFFE 和 SPIRE 为我们的零信任安全架构提供了一个基础认证层。它们允许每个工作负载在开始通信之前以加密方式证明 " 他们是谁”。
摆脱秘密管理
通常，当你想到认证时，你会想到用户名、密码和 bear token。不幸的是，这些类型的凭证正在成为 Amthem 的风险和复杂性的来源。它们往往是长期存在的，对它们的管理或轮换是很棘手的。我们想摆脱这种一般的秘密管理做法。与其问一项服务 “你有什么”，我们想问的是” 你是谁 “。简而言之，我们想转向加密身份，如 SPIFFE。我们可以看到未来使用强证明身份的额外好处，比如在工作负载之间建立相互的 TLS，并将身份传导到应用程序中。
利用 SPIFFE 将安全作为基础设施的一部分来建设
安全往往被开发团队认为是部署的障碍。DevOps 团队希望能更快地部署新的创新功能。然而，他们不得不通过与安全控制有关的人工工单、流程、集成和审查。在 Anthem，我们加倍努力为我们的开发团队消除障碍，使安全成为基础设施的一项功能。随着 SPIFFE 等技术的采用，我们可以将安全控制的复杂性从开发团队中抽象出来，并在各种平台上提供一致的规则。SPIFFE 以及其他基于零信任的技术，将帮助我们在大多数情况下将系统供应时间从三个月缩短到两周以内。在 SPIFFE 的引领下，安全正在成为 Anthem 的一个推动因素。
Square：将信任扩展到云端
Michael Weissbacher 和 Mat Byczkowski，高级安全工程师，Square
Square 提供各种各样的金融服务。在其生命周期中，该公司从内部发展了新的业务部门，如资本和现金，但也收购了 Weebly 和 Stitch Labs 等公司。不同的业务部门使用不同的技术，可以从不同的数据中心和云端运作，同时仍然需要无缝沟通。
我们内部开发的服务识别系统需要扩展到 Square 为其数据中心开发的内部架构之外。我们希望将该系统扩展到云端，我们希望提供一个同样安全的系统，并在未来几年内为我们提供良好的服务。我们最理想的是寻找一个基于开放标准的工具，同时能与 Envoy 代理无缝集成。SPIFFE 和 SPIRE 都支持我们的发展目标，以及与多个云和部署工具合作的独立平台。
一个能与流行的开源项目合作的开放标准
由于 SPIFFE 是基于现有的开放标准，如 X.509 证书，它为我们的服务身份提供了一条清晰的升级路径。Envoy 是 Square 的应用程序如何进行通信的基础构建块。由于 SPIRE 支持 Envoy 的 Secrets Discovery API，因此获得 X509-SVID 很容易。Envoy 内置访问控制，可以使用 SPIFFE 身份来决定允许哪些应用程序进行通信。
我们将 SPIRE 架构与现有的服务身份识别系统并行部署，然后对各种内部工具和框架进行修改，以支持这两个系统。接下来，我们将 SPIRE 与部署系统集成，在 SPIRE 中注册所有服务。这意味着我们可以对 SPIRE 的频繁的 SVID 轮换进行压力测试。最后，我们使用功能标志来慢慢选择服务，使其在服务与服务的调用中开始使用 SVID。
跨云和数据中心的无缝、安全连接
SPIFFE 和 SPIRE 使我们的安全基础设施团队能够提供一个重要的桥梁，安全地连接不同的平台和技术。我们仍处于转移到 SPIRE 的早期迁移阶段，但我们所做的改变使我们能够将我们的生产型 AWS EKS 基础设施与部署在 Square 数据中心的服务无缝连接。我们现在正在努力在我们的信任域之间进行自动联合，因为我们之前只是手动进行联合。我们使用 SPIFFE 身份作为标准，甚至用于我们公司的定制身份工作。
我们也非常高兴能参与到 SPIFFE 社区中来，在我们的旅程中，每个人都很友好，也很有帮助。这个社区还提供了一个额外的好处，那就是为一般的零信任系统提供了一个很好的讨论系统设计想法的地方。