本章介绍了 SPIFFE 的动机和它是如何诞生的。
压倒性的动机和需要
我们到达今天的位置，首先要经历一些成长的痛苦。
当互联网在 1981 年首次广泛使用时，它只有 213 个不同的服务器，而安全问题几乎没有被考虑到 。随着互联计算机数量的增加，安全问题仍然是一个弱点：容易被利用的漏洞导致了大规模的攻击，如莫里斯蠕虫病毒 ，它在 1988 年占领了互联网上的大多数 Unix 服务器，或 Slammer 蠕虫病毒 ，它在 2003 年在数十万台 Windows 服务器上传播。
随着时间的推移，过去的传统周边防御模式已经不能很好地适应不断发展的计算架构和现代技术的边界。各种解决方案和技术层出不穷，以掩盖基础网络安全概念未能跟上现代化趋势而出现的越来越大的裂缝。
那么，为什么周边模式如此普遍，怎样才能解决这些缺陷？
多年来，我们观察到三大的趋势，突出了传统的周边模式对网络未来的限制：
- 软件不再在组织控制的单个服务器上运行。自 2015 年以来，新的软件通常被构建为微服务的集合，可以单独扩展或转移到云主机供应商。如果你不能在需要安全的服务周围画出一条精确的线，就不可能在它们周围筑起一道墙。
- 你不能相信一切，即使是公司内的软件。曾经，我们认为软件漏洞就像苍蝇，我们可以单独拍打；现在，它们似乎更像一群蜜蜂。平均而言，国家漏洞数据库每年报告超过 15000 个新的软件漏洞 。如果你编写或购买了一个软件，它在某些时候可能会有一些漏洞。
- 你也不能相信人，他们会犯错，会心烦意乱，再加上他们可以完全接触到内部服务。首先，每年有数以万计的攻击是基于网络钓鱼 或窃取有效的员工凭证。其次，随着云计算应用和移动工作队伍的出现，员工可以合法地从许多不同的网络访问资源。当人们为了工作而不得不不断地来回穿越这堵墙时，建造一堵墙就不再有意义了。正如你所看到的，对于当今的组织来说，周界安全不再是一个现实的解决方案。当周界安全被严格执行时，阻碍了组织使用微服务和云；当周界安全松懈时，它给了入侵者可乘之机。2004 年，Jericho 论坛认识到需要一个周界安全的继承者。十年后的 2014 年，谷歌发布了一个关于 BeyondCorp 安全架构的案例研究 。然而，两者都没有被广泛的采用。
网络曾经是友好的，只要我们保持自律
最初的互联网使用案例集中在学术界，目的是分享信息，而不是组织意外访问。当其他组织开始将联网的计算机系统用于商业敏感的场景时，他们在很大程度上依赖于物理周界和物理证明，以保证访问网络的个人得到授权。当时还不存在受信任的内部威胁的概念。随着网络从学术用途发展到商业用途，软件从单体发展到微服务，安全成为增长的障碍。
最初，通过防火墙、网络分段、私有地址空间和 ACL 来模拟墙和警卫来保护计算机的物理访问的传统方法。这在当时是有意义的，特别是考虑到需要控制的点的数量有限。
随着网络的扩散，以及用户和商业伙伴访问点的增加，通过安全地交换和管理密钥、凭证和令牌，物理身份验证（常见于墙和警卫）变得虚拟化，随着技术和需求的发展，所有这些都变得越来越有问题。
采用公共云
从传统的内部部署和数据中心运作迁移到公共云，放大了现有问题。
随着人们获得了在云中创建计算资源的自由，企业内的开发团队和运维团队开始更紧密地合作，并围绕着专注于软件自动化部署和管理的 DevOps 概念形成新的团队。公共云快速发展的动态环境使团队能够更频繁地进行部署 —— 从每几个月部署一次，到每天部署多次。按需配置和部署资源的能力使人们能够高速创建专门的、有针对性的、可独立部署的服务套件，其责任范围较小，俗称为微服务。这反过来又增加了跨部署集群识别和访问服务的需要。
这种高度动态和弹性的环境打破了公认的边界安全概念，需要更好的服务水平互动，与基础网络无关。传统的边界执行使用 IP 和端口进行认证、授权和审计，在云计算范式下，这不再是干净地映射到工作负载。
公共云的参与所激发的模式，如 API 网关或用于多服务工作负载的管理的负载均衡器，强调了对不依赖网络拓扑或路径的身份的需求。保护这些服务间的通信的完整性变得更加重要，特别是对于需要跨工作负载统一性的团队。
休斯顿，我们有一个问题
随着企业采用新技术，如容器、微服务、云计算和无服务器功能，有一个趋势是明确的：更多更小的软件。这既增加了攻击者可以利用的潜在漏洞的数量，也使得管理周边防御越来越不现实。
这种趋势正在加快，这意味着越来越多的组件被部署在自动化基础设施上，往往牺牲了安全和保障。绕过手动流程，如防火墙规则票或安全组的变化，并非闻所未闻。在这个新的现代世界里，无论部署环境如何，面向网络的访问控制都会迅速过时，需要不断维护。
这些规则和例外情况的管理可以自动化，然而，它们需要迅速发生，这在较大的基础设施中可能是一个挑战。此外，网络拓扑结构，如网络地址转换（NAT），会使其变得困难。随着基础设施变得越来越大，越来越动态，依靠人力的系统根本无法扩展。毕竟，没有人愿意花钱请一个整天玩弄防火墙规则的团队，而他们仍然无法跟上需求的进度。
依靠特定地点的细节，如服务器名称、DNS 名称、网络接口细节，在一个动态调度和弹性扩展的应用世界里有几个缺点。虽然网络结构的使用很普遍，但该模型是软件身份的一个无效的模拟。在应用层，使用传统的用户名和密码组合或其他硬编码的凭证，可以赋予一定程度的身份，但更多的是处理授权而不是认证。
在软件开发生命周期的早期整合安全并引入反馈，使开发人员能够对其工作负载的识别和信息交换机制进行更多的操作控制。有了这种变化，授权政策的决定可以委托给个别服务或产品所有者，他们最适合做出与有关组件相关的决定。
重新认识访问控制
在采用公有云之前，企业所经历的问题不断增加，而采用公有云后，企业又痛苦地出现了问题，这就推动了传统的周界是不够的，需要有更好的解决方案的概念。最终，去边界化意味着企业需要弄清楚如何识别他们的软件并实现服务对服务的访问控制。
解决方案之一：秘密
像密码和 API 密钥这样的共享秘密为分布式系统的访问控制提供了一个简单的选择。但这种解决方案也带来了许多问题。密码和 API 密钥很容易被泄露（试着在 GitHub 上搜索 “client_secret” 这样的短语，看看会发生什么）。在大型组织中，秘密可能很难因泄露而轮换，因为每个服务都需要以一种协调的方式意识到变化（而错过一个服务可能会导致停工）。
诸如 HashiCorp Vault 这样的工具和秘密存储库已经被开发出来，以帮助缓解秘密管理和生命周期的困难。虽然也有许多其他工具试图解决这个问题，但它们往往提供了一个更加有限的解决方案，效果平平（见 Secrets at Scale: Automated Bootstrapping of Secrets & Identity in the Cloud ）。有了所有这些选择，我们最终还是回到了同一个问题上：工作负载应该如何获得对这个秘密库的访问？仍然需要一些 API 密钥、密码或其他秘密。
所有这些解决方案最终都会出现“乌龟下面还有一只乌龟" 的问题。
- 启用对资源的访问控制，如数据库或其他资源。
- 服务需要一个秘密，如 API 密钥或密码。
- 该钥匙或密码需要被保护，所以你可以保护它，比如说用加密。但是，你仍然担心密码的解密密钥。
- 该解密密钥可以被放入秘密库，但这样你仍然需要一些凭证，如密码或 API 密钥来访问秘密库。
- 最终，为了保护对秘密的访问会产生需要保护的一个新秘密。
为了打破这个循环，我们需要找到一个底层乌龟，也就是说，一些秘密提供了对我们所需的认证和访问控制的其他秘密的访问。一种选择是在服务部署时手动提供秘密。然而，这在高度动态的生态系统中是无法扩展的。随着企业转向具有快速部署管道和自动扩展资源的云计算，随着新计算单元的创建，手动配置秘密变得不可行。而当一个秘密被破坏时，使旧的凭证失效会带来使整个系统崩溃的风险。
在应用程序中嵌入一个秘密，这样它就不需要手动配置了，其安全属性甚至更差。嵌入到源代码中的秘密有一个习惯，那就是出现在公共存储库中（你试过我建议的 GitHub 搜索吗）。虽然秘密可以在构建时被嵌入到机器镜像中，但这些镜像最终还是会被意外地推送到公共镜像库中，或者作为杀毒链的第二步从内部镜像库中提取。
我们希望有一种解决方案，不包括长期存在的秘密（这些秘密很容易被破坏，也很难轮换），也不需要人工向工作负载提供秘密。为了实现这一点，无论是在硬件还是在云提供商，都必须有一个信任的根，在此基础上建立一个以软件（工作负载）身份为中心的自动化解决方案。然后，这种身份构成了所有需要认证和授权的互动的基础。为了避免产生另一个底层乌龟，工作负载需要能够在没有秘密或其他凭证的情况下获得这一身份。
迈向未来
自 2010 年以来，业界为解决软件身份问题进行了多种努力。谷歌的低开销认证服务（LOAS），后来被命名为应用层传输安全（ALTS） ，建立了一个新的身份格式和有线协议，用于从运行时环境接收软件身份，并将其应用于所有网络通信。它被称为拨号音安全（dial tone security）。
在另一个例子中，Netflix 的内部开发的解决方案（代号为 Metatron ）通过利用云 API 来证明实例上运行的机器镜像，并通过 CI/CD 集成来产生机器镜像和代码身份之间的加密绑定，从而在每个实例基础上建立软件身份。这种软件身份采取 X.509 证书的形式，对服务间的通信进行相互认证，包括访问作为该解决方案一部分开发的秘密服务，在此基础上实现秘密管理。
业界的其他一些努力，包括来自 Facebook 等公司的努力 ，证明了对这样一个系统的需要，并强调了实施的难度。
普适安全生产身份框架（SPIFFE）的愿景
在成立通用的解决方案之前，需要建立一个框架编码原则。Kubernetes 的创始工程师 Joe Beda 在过去的工作中接触过各种技术，这些技术使工程团队的生活更加轻松，他在 2016 年开始呼吁为生产身份创建一个解决方案，作为一个专门的解决方案，旨在以一种通用的方式解决问题，可以在许多不同类型的系统中利用，而不是以艰难的方式进行 PKI 的中间解决方案。这种公司之间的大规模合作努力，为基于 PKI 的服务身份开发了一个新的标准，这就是 SPIFFE 的开始。
2016 年 Beda 在 GlueCon 上发表的论文 展示了一个具有这些参数的难题：
- 通过利用基于内核的自省来获得关于调用者的信息，而无需调用者出示凭证，从而解决零号秘密的问题。
- 使用 X.509，因为大多数软件已经兼容，而且
- 有效地将身份的概念从网络定位器中剥离出来。
在引入 SPIFFE 概念之后，Netflix 服务认证方面的专家举行了一次会议，讨论原始 SPIFFE 提案的最终形态和可行性。许多成员已经实施了、继续改进并重新解决了工作负载识别问题，突出了社区合作的机会。参加会议的成员希望获得彼此之间的互操作性。这些专家意识到他们已经实施了类似的解决方案来解决同样的问题，可以建立一个共同的标准。
解决工作负载身份问题的最初目标是建立一个开放的规范和相应的生产实现。该框架需要在不同的实现和现成的软件之间提供互操作性，其核心是在一个不信任的环境中建立信任的根基，驱除隐性信任。最后，摆脱以网络为中心的身份，以实现灵活性和更好的扩展特性。
