第 10 章 从业者故事
原书：Chapter 10. Practitioners' Stories（p.168–178） 翻译策略：技术直译 + 段落重排；专有项目名、协议名、API 名、CLI 命令、配置字段、证书/加密术语一律保留英文；首次出现的关键概念以"中文（English）"形式给出，后续沿用英文。术语对照见
TERMS.md。
章节导言
本章包含来自五位实践者的故事——他们都是部署过 SPIFFE 和 SPIRE 的真实业务公司的工程师。
Uber：用加密身份保护新一代与传统基础设施
作者：Ryan Turner，Software Engineer 2，Uber
过去十年，Uber 已经成为爆炸式增长的代名词。随着软件服务数量和我们运行的地理范围的扩大，复杂度和风险也在增长。为了满足这些不断增长的需求，我们开始构建我们的下一代基础设施平台。同时，几年之前，我们就看到了开源项目 SPIFFE 和 SPIRE 的早期势头。
我们立即看到了 SPIFFE 能带来的价值——它能让我们加强新一代基础设施的安全姿态。我们已经在 Uber 内部上线了 SPIRE，现在正用它来在各种工作负载环境之间、用密码学可验证的身份建立信任。我们从一些应用服务和内部服务开始，比如一个工作流引擎——它通过访问平台上的数据来拉起多个动态工作负载，以完成特定任务。SPIRE 在我们整个应用生命周期中向工作负载提供 SPIFFE 身份。SPIFFE 被用来认证服务，并帮我们避免可能导致生产问题的配置错误。
把 SPIRE 改造进遗留栈
SPIRE 现在是 Uber 下一代基础设施的关键组件，但我们也在用一种 side-car 的方法把身份认证改造进遗留基础设施。虽然 SPIFFE 和 SPIRE 通常被认为在现代云原生架构中工作得很好，我们可以快速地把这些项目适配到我们专有的遗留栈。SPIRE 能为 Uber 的新一代和遗留基础设施之间的信任搭起一座关键的桥梁，并对内部安全和开发者效率产生积极影响。
在我们前行的道路上，SPIFFE 社区在帮我们寻找方案这件事上提供了非常多的支持。结果，我们的工程师们也一直在积极地为这些项目贡献代码。
安全、开发和审计团队都从 SPIFFE 受益
SPIFFE 给我们的安全团队对后端基础设施更大的信心，并减少了对基于网络的安全控制的依赖。由于我们处理的是金融数据、且跨地理边界运营，我们必须控制对金融和客户数据的访问。借助 SPIRE，我们可以为访问控制提供一个"强证明"的身份。它帮我们满足这些要求、并减轻审计团队的负担。
Uber 的开发团队用一致的客户端库，基于 SPIFFE 身份创建 AuthZ 策略。这些项目让开发团队能够利用 X.509 和 JWT 等工作负载身份原语——而无需对信任 bootstrap、安全引入、凭据提供与轮换等复杂话题有深入理解。
Pinterest：用 SPIFFE 化解"身份危机"
作者：Jeremy Krach，Senior Security Engineer，Pinterest
2015 年，Pinterest 经历了一场身份危机。公司的基础设施在多种、且互不相交的方向上不断扩张。每个新系统都以它独特的方式解决身份认证问题。开发者们每个月要花数小时开会、做安全评审——去设计、威胁建模、并实现自己定制化的身份方案，或者把新服务与依赖的异构身份模型做集成。情况变得很明显：安全团队需要构建一套通用基础设施——以"通用"的方式提供身份、能被我们所有异构服务复用。
这套系统的初版把身份以"基于主机名的 X.509 证书"的形式委托给机器。它被重度用于秘密管理（见 Knox，github.com/pinterest/knox），但尚未被更广泛地采纳。随着我们继续扩展——特别是多租户系统（如 Kubernetes）——我们需要更细粒度的身份——这些身份不绑死在基础设施中的特定主机上，而是绑死在"服务自身的身份"上。SPIFFE 应运而生。
用 SPIFFE 把复杂性抹平
SPIFFE 现在为我们的基础设施中大部分提供统一身份。我们最初从 Kubernetes 入手，因为那个多租户环境里的需求最迫切。后来我们把基础设施的其余部分也迁到 SPIFFE，作为主要的身份形式。结果，Pinterest 上几乎每个服务都有一个我们能用的标准名字——再没有那些晦涩的约定和零碎的方案。它帮我们统一并标准化了身份约定——并与我们其他标识"服务属性"（如服务所有者）的内部项目保持一致。
我们在 ACL 中把 SPIFFE 作为身份——用于秘密管理、用于服务间互信 TLS 通信、甚至用于通用授权策略（通过 OPA，www.openpolicyagent.org，另一个 CNCF 项目）。Pinterest 开源的秘密管理服务 Knox 把 SPIFFE X.509 身份文档作为一种受支持的身份认证方法。参见我们关于"把 SPIFFE 支持加入 Knox"的博客文章：medium.com/pinterest-engineering/secret-managem...。
开发、安全与运维重归和谐
SPIFFE 让安全团队写授权策略更容易。开发者速度显著提升——我们的工程师不必为每种定制方案或不同的认证集成担忧。由于现在我们有一套"跨基础设施解释身份"的标准方式，计费与所有权团队也更易判断"一个服务由谁负责"。强烈的"身份感"对日志与追踪的一致性也很有帮助。我们对 SPIFFE 项目的未来感到兴奋，也感谢它帮助我们化解了身份危机！
ByteDance：为 Web 级服务提供"拨号音"式认证
作者：Eli Nesterov，Security Engineering Manager，ByteDance
ByteDance（TikTok 背后的公司）已经构建并部署了全球性的大规模互联网服务，惠及数百万用户。支持这些服务的基础设施是私有数据中心和公有云厂商的混合。我们的应用跑在多个 Kubernetes 集群和跨平台的专用节点上，形式是成千上万的微服务。
随着我们规模与体量的增长，我们在各平台上有多种认证机制——从 PKI、JWT token、Kerberos、OAuth，到自研框架，不一而足。再加上多种编程语言与这些认证机制的组合，运营的复杂度和风险更是与日俱增。运维上，对我们的安全和运维团队来说管理这些认证方案变得很复杂。当认证框架出现已知漏洞时，我们无法快速行动——每个框架都得单独处理。有些甚至有代码级依赖，更改起来更困难。跨地理边界的审计与合规也很具挑战性——每个平台特定的认证方法都得单独审查和治理。
走向基于零信任的架构，以及改进开发者生产力的努力，迫使我们构建一套统一的服务身份管理平面
在我们这样的规模和复杂性下，构建一个能跨不同基础设施"孤岛"或平台工作的身份系统很难。我们本可以自己造一套，但那会需要大量努力。我们选择 SPIRE——它提供了我们所需的"在各种平台上支持 web 规模"的扩展性与灵活性。由于它提供了基于标准 X.509 证书的加密身份，它帮我们轻松启用互信 TLS——而互信 TLS 默认就能满足许多合规要求。可扩展性、开源——也是加分项——因为我们可以方便地把它集成进我们既有的控制平面和数据栈。
透明认证简化了运维
有了 SPIRE，我们能在所有平台上部署一套一致的、"拨号音"式的认证。认证和安全的负担现在从开发者身上卸载了——他们可以专注于业务或应用逻辑。这全面提升了我们的部署速度。我们也更不容易因为配置问题（比如在生产环境用了开发环境的凭据）而出现"生产错误"。
通过 SPIRE 实现的标准化认证也简化了合规与审计——因为我们跨 Trust Domain 和平台具备了互信 TLS。SPIRE 还让我们能够走向一种"半去中心化"的身份分发模型——身份系统是本地的，比如本地于某个数据中心。这提升了我们的整体可用性、也为恢复提供了更好的位置。
我们基本上用 SPIRE 实现了"面向未来"——因为它能扩展、也能适应，去满足我们不断增长的业务需求。
Anthem：用 SPIFFE 保护云原生医疗应用
作者：Bobby Samuel，VP AI Engineering，Anthem
医疗行业不断上升的成本，正在促使像 Anthem 这样的组织快速创新、并重新思考我们与医疗机构、雇主团体、个人的交互方式。作为这一举措的一部分，我们正在开发一大批应用——它们将通过安全地开放医疗数据访问来帮我们降低成本。我们已经开始构建支撑性的下一代基础设施——基于 Kubernetes 等云原生技术。这套新基础设施将驱动快速创新、并接入更广泛的组织与开发者生态。这方面的一个例子是我们的 HealthOS 平台。HealthOS 将让第三方构建 HealthApp 能力——交付到前端界面——利用一片去标识化的健康数据海洋。
但几乎在每一家大型企业——尤其在医疗组织——都有人试图以恶意目的获取他们的数据。受保护的健康信息（PHI）的售价远高于金融信息；因此，恶意行为者（无论是黑客还是脚本小子）都觉得医疗系统和其中的健康信息是块肥肉。随着云原生架构的采用，风险与复杂度进一步上升。发生泄露的风险更高——因为威胁半径显著扩大——而手工的安全评审与流程又成为阻碍云扩展的瓶颈。
为零信任架构构建基础
我们不能依赖传统的"基于边界"的安全工具和流程来保护我们的下一代应用与基础设施。零信任——一种细粒度、自动化的安全方法——对我们来说特别有意义，尤其是未来，因为我们计划跨组织边界、跨云厂商运营。
对用户和对服务的身份与认证是零信任安全模型的核心原则之一。零信任让我们更少依赖基于网络的控制、更多依赖"对每个系统或工作负载进行认证"。SPIFFE 和 SPIRE 已经为我们的零信任安全架构提供了一层基础认证能力。它们让每个工作负载能在开始通信前、用密码学证明"我是谁"。
远离秘密管理
通常当你想认证时，你会想到用户名、密码、bearer token。不幸的是，这类凭据在 Anthem 越来越成为风险和复杂度的来源。它们往往是长期存在的，管理与轮换它们都很难。我们想总体上远离这种秘密管理实践。我们想问服务的不是"你有什么"、而是"你是谁"。简言之，我们想转向像 SPIFFE 这样的加密身份。我们能看到在未来使用"强证明"身份的更多收益——比如在工作负载之间建立互信 TLS、把身份向上冒泡到应用层。
把安全作为基础设施的一部分用 SPIFFE 构建
在开发团队眼里，安全往往是部署的阻碍。DevOps 团队想更快地部署新的创新特性。然而，他们必须为安全控制走手工工单、流程、集成、评审。在 Anthem，我们加倍努力——通过把安全变成基础设施的一项功能——来为开发团队清除障碍。随着像 SPIFFE 这样的技术被采用，我们能够把安全控制的复杂性从开发团队那里抽离出来、并跨平台提供一致的规则。SPIFFE，连同其他基于零信任的技术，将帮我们把系统上线时间从三个月缩短到大多数场景下的两周以内。在 Anthem，安全正在成为一种使能因素——SPIFFE 走在最前列。
Square：把信任延伸到云端
作者：Michael Weissbacher 与 Mat Byczkowski，Senior Security Engineers，Square
Square 提供各种各样的金融服务。Square 在其生命周期的不同阶段，从内部生长出新的业务单元——比如 Capital 和 Cash——也收购了 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 轮换做压力测试。最后，我们用 feature flag 让服务逐渐开始"在服务到服务调用中使用 SVID"。
跨云与数据中心无缝、安全的连接
SPIFFE 和 SPIRE 正在让我们的安全基础设施团队在不同的平台与技术之间提供一座关键的桥——让它们安全地相连。我们还处在迁移到 SPIRE 的早期阶段，但已经落地的改造让我们能把生产环境中的 AWS EKS 基础设施与部署在 Square 数据中心里的服务无缝连接起来。我们现在正在做跨 Trust Domain 的自动联邦——之前我们都是手工联邦的。我们甚至在公司内部做的定制身份工作中也把 SPIFFE 身份作为一项标准。
我们也非常乐意参与到 SPIFFE 社区中来——在我们的旅程中，大家都很友好、很有帮助。社区还带来了一个额外的好处——它是一个讨论零信任系统设计思路的好地方。
下一章：附录：术语表（Glossary）