写在前面
新一代网络安全方法已经超越了传统的基于边界的安全模型，在传统的基于边界的安全模型中，“墙”可以保护边界，并且内部的任何用户或服务都将受到完全信任。在云原生环境中，仍然需要保护网络外围，但是仅靠这种安全方法还远远不够——如果防火墙不能完全保护公司网络，那么它也不能完全保护生产网络。
云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式API。这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段，云原生技术使工程师能够轻松地对系统作出频繁和可预测的重大变更。
2014年，谷歌开始对外介绍BeyondCorp，这是一种用于用户访问企业网络的网络安全模型。BeyondCorp基于零信任架构原则，重新定义了企业网络访问。在此同时，谷歌同样还将零信任架构应用于其如何连接机器，工作负载与服务之中。这个项目就是BeyondProd。
在BeyondProd中，谷歌设计并实践了以下安全原则：
在边缘保护网络；
服务间默认不互信；
在可信机器上运行来源已知的代码；
跨服务强制执行一致策略的关卡；
发布流程更改实现简单化、自动化及标准化；
工作负载之间进行隔离。
简言之，谷歌通过多种控件和模块，实现容器及在其中运行的微服务能够安全部署，彼此间安全通信，彼此相邻安全运行，而不会给单个微服务开发人员增加基础架构的安全性和实现细节的负担。
关于译者：奇安信身份安全实验室，奇安信集团下属专注“零信任身份安全架构”研究的专业实验室，翻译并出版了业界首部零信任安全技术图书《零信任网络：在不可信网络中构建安全系统》。该团队以“零信任安全，新身份边界”为技术思想，推出“以身份为基石、业务安全访问、持续信任评估、动态访问控制”为核心的奇安信零信任身份安全解决方案。该团队结合行业现状，大力投入对零信任安全架构的研究和产品标准化，积极推动“零信任身份安全架构”在业界的落地实践，其方案已经在部委、央企、金融等行业进行广泛落地实施，得到市场、业界的高度认可。
BeyondProd：一种新的云原生安全方法
谷歌在此前已经撰写了几篇白皮书来介绍有助于提高安全性的谷歌内部开发项目。在本文中，BeyondProd特意沿用了BeyondCorp的概念——正如边界安全模型不再适用于终端用户一样，它也同样不再适用于微服务场景。对照BeyondCorp文中的话来讲：“此模型的关键假设不再成立：边界不再仅仅是企业[数据中心]的实际位置，且边界内的区域也不再是托管个人计算设备和企业应用程序[微服务]的安全可靠之处。”
本文将详细介绍，谷歌的多个基础架构是如何在一个如今被称为“云原生（cloud-native）”的架构中进行协同工作来保护工作负载（workload）的。有关谷歌安全的概述，可参阅《安全架构设计白皮书》。
本文记录内容截至到2019年12月是正确无误的。本文仅代表截止撰文时的状态。随着谷歌持续改善对用户的保护机制，谷歌云的安全政策和系统未来可能会发生变化。
术语库
本文采用以下定义：
微服务（microservice）将应用需要执行的单个任务（task）分离成多个单独的服务（service），每个服务都可独立进行开发和管理，并具有自己的API、发布环节、扩展和配额管理。在更现代化的体系架构中，一个应用（如一个网站）可以作为微服务的集合而运行，而不再作为某个单体应用。微服务具有独立化、模块化、动态化和短时化的特征。它们可分布在众多主机、集群，乃至云端。
工作负载（workload）是应用完成的特有任务。在微服务架构中，工作负载可以是一个或多个微服务。
作业（job）是运行一个应用某个部分的单个微服务实例。
微服务使用服务身份（service identity）向基础架构中运行的其他服务证明自己身份。
服务网格（service mesh）是服务和服务间通信的基础架构层，可以控制流量、应用策略和集中监控服务调用。使用微服务架构时，可以消除由单个服务执行这些控制措施的负担，并允许跨多个微服务进行更简单的集中管理。
面向CIO的概要
谷歌的基础架构将工作负载作为单独的微服务部署在容器中，并使用Borg（谷歌的容器编排系统）来管理这些工作负载。这就是如今众所周知的“云原生”架构的灵感和模版来源。
谷歌的基础架构在设计之初就将安全性纳入考虑，而不是在事后补充。谷歌的基础架构默认假定各服务之间互不信任。
谷歌通过一项名为BeyondProd的计划来保护微服务。保护内容包括如何更改代码以及如何访问微服务中的用户数据。BeyondProd应用的概念包括：进行双向身份认证的服务端点、传输安全、具备全局负载均衡和拒绝服务防护能力的边缘终结、端到端源代码溯源和运行时沙箱。
从传统的安全模型向云原生安全模型迁移，需要对基础架构和开发过程这两个主要方面进行更改。在包含和连接所有微服务的共享结构（也称为服务网格）中构建共享组件，可以更轻松地发布变更并实现跨服务的一致安全性。
动机
谷歌向容器化和容器编排化演进，是为了获得更高的资源利用率，构建高可用的应用，并简化谷歌开发人员的工作。促使谷歌向容器化基础架构演进的另一个理由是为了让我们的安全控制措施与架构保持一致。我们已经清楚地认识到，以网络边界为中心的安全模型不够安全。一旦攻击者突破了边界，就可以在网络中畅行无阻。虽然我们意识到需要加强整个基础架构中的安全控制措施，但同时也希望谷歌的开发人员能够轻松编写和部署安全的应用，而不必自己动手去实现这些安全能力。
从单体应用演进到使用编排系统从容器部署的分布式微服务有着明显的操作优势：让管理和扩展更为简单。这种云原生架构需要使用不同的安全模型和不同的工具来实现保护与微服务的管理和可扩展优势协调一致的部署。
本文将描述谷歌如何实施云原生安全，即BeyondProd：转变到云原生架构对安全的意义，云原生安全的安全原则，为满足这些需求而构建的系统，以及各位读者将如何在自身实现类似改变的一些指南。
谷歌的云原生安全
容器化微服务
自公司成立初期，谷歌就有意识地决定采用低成本的商用服务器来扩大数据中心的容量，而不是投资价格昂贵的高可用性硬件。我们一直以来、并将在未来持续实践一套可靠的指导原则，即系统任何单一部分发生故障都不应影响用户所能看到的服务的可用性。要实现这种可用性，需要运行冗余的服务实例，这样单个故障的发生才不会导致服务中断。基于这种原则，我们才开发了容器、微服务及容器编排技术，以灵活管理这些高度冗余和分布式系统的部署。
容器化的基础架构意味着每个工作负载都要部署一组属于自己的不可变、可移动、可调度的容器。为了在内部管理这些容器，我们开发了一套名为Borg的容器编排系统[1]，目前我们仍通过它来实现每周部署数十亿个容器。
容器使得工作负载更易于在机器之间进行封装和重新调度。微服务使开发和调试应用的不同部分变得更容易。将微服务和容器两者结合使用，可以将工作负载拆分成更小、更易于管理的单元，以便进行维护和发现。采用具有微服务架构的容器化基础架构被称为采用“云原生”。服务在Borg部署的容器中运行。该架构可以根据需要扩展工作负载——如果对特定工作负载有很高的需求，则可能有多台计算机运行同一服务的副本以处理所需规模的工作负载。
谷歌的一个与众不同之处就在于，我们在架构的每一次演进中都考虑到了安全性。最新的这个云原生安全的概念与谷歌多年来用于保护基础架构的理念相当。我们微服务体系架构和开发过程的目标是在开发和部署生命周期中尽早解决安全问题——在这个阶段解决问题的成本较低——并通过保持标准和持续一致的方式加以解决。最终的结果是，开发人员在确保安全性方面花费的时间更少，同时仍然能获得更安全的效果。
迁移到云原生架构
现代的安全体系架构已经超越了基于边界的传统安全模型——采用防火墙保护边界，完全信任防火墙内部的任何用户或服务。BeyondCorp项目即现代企业用户的工作方式变化的一种应对方式。如今，用户采用移动办公方式，常常会在组织的传统安全边界之外工作，例如在咖啡店、飞机或其他的任何地方。在BeyondCorp中，我们放弃了特权企业网络的概念，并且仅基于设备和用户凭据和属性进行授权访问，不管用户的网络位置如何。
云原生安全解决了服务及其用户所面临的共同问题——在云原生环境中，不能仅仅依靠防火墙来保护生产网络，就像不能仅仅依赖防火墙来保护企业网络一样。正如用户并非都在使用同一个物理位置或设备一样，开发人员也并非都会将代码部署到同一个环境中。借助BeyondProd，微服务不仅可以运行在防火墙保护下的数据中心中，还可以运行在公有云、私有云或第三方托管服务中，并且在任何地方都能确保它们的安全。
正如用户会移动、会使用不同的设备、会从不同的位置连接一样；微服务也会移动、会跨异构主机、会部署在不同的环境中。BeyondCorp认为“用户信任应取决于设备的上下文感知状态等特性，而不应取决于连接到公司网络的权限”，与此对应，BeyondProd认为“服务信任应取决于代码来源和服务身份等特性，而不应取决于在生产网络中的位置，如IP或主机名身份”。
云原生架构和应用开发
只专注于基于边界的安全作为一种相对更传统的安全模型，无法独立保护云原生架构。举个例子，采用三层架构的单体应用被部署到公司的私有数据中心，该中心有足够的容量来处理关键事件的峰值负载。对硬件和网络有特定要求的应用会特意部署到通常保留固定IP地址的特定机器上。更新的发布频率较低、规模较大，且很难协调，因为更新所带来的更改会同时影响应用的许多部分。这会导致应用的生命周期过长，而且更新频率较低，同时使用安全补丁的频率也通常较低。
但是，在云原生模型中，容器将应用所需的二进制文件与底层主机操作系统分离，使应用更具可移植性。容器的不可变性意味着它们一旦部署就不会发生更改——因此它们可以被频繁地重新构建及重新部署。作业具有可扩展性可以很好地处理负载：在负载增加时可部署新的作业，当负载减少时可终止现有作业。由于容器会频繁重启、终止或重新调度，因此硬件和网络的重复使用和共享会更加频繁。采用通用的标准化构建和分发流程，会使得团队之间的开发流程更一致、统一，即使团队独立管理其微服务的开发也是如此。因此，安全考虑（例如安全审核、代码扫描和漏洞管理）可以在开发周期的早期阶段进行。
对安全的影响
前面已经详细介绍了关于内部不可信的模型——类似BeyondCorp中的用户——可以如何应用到BeyondProd中的微服务，但这种转变究竟是怎样的？下表1对传统基础架构的安全性方面与云原生架构中的安全性方面的不同进行了对比。表1还描述了从传统架构迁移到云原生架构需要满足的相关要求。本节其余部分为针对表的每一项进行详细描述。
表1：迁移到云原生架构时隐含的安全性要求
从基于边界的安全到零信任安全
在传统的安全模型中，组织的应用可以依赖其私有化数据中心周围的外部防火墙来防护入站流量。但在云原生环境中，尽管像在BeyondCorp模型中一样仍然需要保护网络边界，但仅基于边界的安全模型已经远不再安全。这并不是在说我们遇到了新的安全问题，而是会让人注意到一个事实：如果防火墙无法完全保护企业网络，它就无法完全保护生产网络。在零信任安全模型中，无法再对内部流量保留隐式信任——它需要其他安全控制措施，如身份认证和加密。同时，向微服务的转变提供了重新思考传统安全模型的机会。当消除对单一网络边界（如防火墙）的依赖时，就可以按服务进一步划分网络。进一步来说，可以进行微服务级别的分段，使得服务间没有固有的信任。通过微服务，流量可以有不同的信任级别并且使用不同的控制措施——不再只是比较内部流量与外部流量。
从固定IP地址和硬件到更大的共享资源
在传统安全模型中，组织的应用部署在专用机器上，且这些机器的IP地址不常变化。这意味着安全工具可以靠相对静态的架构映射，通过可预测的方式关联应用——如防火墙等工具中的安全策略可以用IP地址作为标识符。
但是，在云原生环境中，由于共享主机和频繁更改的作业，通过防火墙来控制服务间访问的方式行不通。特定IP地址与特定服务相关联的设定将不再有效。因此，身份应基于服务，而不应基于IP地址或主机名。
从特定于应用的安全实施到集成在服务堆栈中的共享安全要求
在传统安全模型中，每个应用只负责满足自身的安全要求，而不用考虑其他的服务。这些要求包括身份管理、SSL/TLS终止和数据访问管理。这常常导致实施方式不一致或安全问题得不到解决，并且由于在很多地方都需要解决这些问题，这就使得修复措施更难实现。
在云原生环境中，服务之间会更频繁地重复使用组件，并且会有关卡来确保跨服务一致强制执行政策。可以通过不同的安全服务来执行不同的安全策略。与其要求每个应用分别实现关键的安全服务，不如将不同的安全策略拆分为单独的微服务（例如，一个策略用于确保对用户数据的授权访问，另一个策略用于确保使用最新的TLS密码套件）。
发布流程从定制更新且频率较低到标准更新且频率更高
在传统安全模型中，共享服务很有限。如果代码分散各处，加上本地化开发，意味着很难确定涉及应用许多部分的更改所造成的影响——因此，更新的发布频率较低且难以协调。要进行更改，开发人员可能需要直接更新每个组件（例如，通过SSH连接到虚拟机来更新配置）。总的来说，这会导致某些应用的生命周期变得过长。从安全性角度来看，由于代码更分散，因此审核难度更大，而且更难确保在修复漏洞时，在任何地方都能修复该漏洞。迁移到频繁、标准化发布更新的云原生架构后，安全设计在软件开发生命周期中的位置会左移[2]。这样可以实现更简单、更一致的安全性强制执行措施，包括定期应用安全补丁程序。
从使用物理机或hypervisor进行工作负载隔离到需要更强的隔离能力使得可在同一台机器上运行封装式工作负载
在传统安全模型中，工作负载被调度到自己的实例上，没有共享资源。应用被机器和网络边界有效隔开，工作负载隔离完全依靠物理主机不同、hypervisor（虚拟机监控程序）和传统防火墙来实现。
在云原生环境中，工作负载装入容器并封装到共享主机和共享资源上。因此，需要在工作负载之间建立更强的隔离。在使用网络控制和沙箱技术的部分中，工作负载可以分离为彼此隔离的微服务。
安全原则
在开发云原生架构的同时希望增强其安全性——因此我们制定并优化了以下安全原则：
在边缘保护网络，使工作负载与来自互联网的网络攻击和未经授权流量隔离开。虽然基于防火墙的方法不是云原生架构的新概念，但它仍不失为一种有效安全实践。在云原生环境中，通过基于边界的防护方法用来保护尽可能多的基础架构，使其避开来自互联网的未经授权的流量和来自潜在的攻击，例如基于容量的拒绝服务攻击。
服务间默认不互信，只有已知的、可信的和明确授权的调用者才能使用服务。这可以阻止攻击者使用不可信代码访问服务。如果某项服务确实被破坏，这会阻止攻击者执行允许其扩大访问范围的操作。这种互不信任有助于限制破坏的爆炸半径。
在可信机器上运行来源已知的代码，因此服务身份仅限于使用授权代码和配置，并且只能在经过验证的、授权环境中运行。
跨服务强制执行一致策略的关卡。例如，一个用于验证访问用户数据请求的关卡，如此服务的访问来自获得授权的最终用户发出且经过验证的请求，并且管理员的访问需要提供正当的理由。
发布流程更改实现简单化、自动化及标准化，以便相关人员轻松审核基础架构更改对安全性的影响，并且可以在几乎不影响生产环境的情况下发布安全补丁程序。
共享操作系统的工作负载之间的隔离，如果一个服务被破坏，不会影响在同一台主机上运行的其他工作负载的安全性。这限制了潜在破坏的“爆炸半径”。
在整个基础架构中，我们的目标是实现不依赖于人的自动化安全。安全的扩展方式应与服务的扩展方式相同。在默认情况下，服务应该是安全的；在异常情况下，服务应该是不安全的——人工操作应该异常情况下进行，而不是作为日常事务，并且人工操作应该可审核。然后，我们可以根据为某项服务部署的代码和配置而不是部署服务的人员来对服务进行身份认证。
综上，这些安全原则的实施意味着容器和运行在其中的微服务可以部署、相互通信及并行运行，而不削弱云原生架构的属性（即简单的工作负载管理、可无运维扩展和有效封装）。所有这些都可以实现，而无需再向单个微服务开发人员提供底层基础架构的安全属性和实现细节。
谷歌的内部安全服务
为了保护谷歌的云原生架构，我们设计并开发了多种内部工具和服务。下列安全服务都用于实现上节“安全原则”中定义的相关安全原则：
谷歌前端（Google Front End, GFE）：终止来自最终用户的连接，并为强制执行TLS最佳实践提供了一个中心点。尽管我们不再强调基于边界的安全模型，但GFE仍然是保护内部服务免受拒绝服务攻击的重要策略部分。GFE是用户连接谷歌网络的第一个入口点；在基础架构中，GFE还根据需要在区域之间平衡负载和重新路由流量。GFE是将流量路由到适当微服务的边缘代理。
应用层传输安全（Application Layer Transport Security, ALTS）：用于RPC身份验证、完整性和加密。ALTS是谷歌基础架构中服务间相互认证和传输加密的系统。身份通常绑定到服务，而不是绑定到特定的服务器名或主机。这有助于实现跨主机的无缝微服务复制、负载平衡和重新调度。
Borg的二进制授权（Binary Authorization for Borg）和主机完整性（Host Integrity）分别用于微服务和机器完整性验证：
Borg的二进制授权（BAB）:在部署时进行强制检查可以确保代码在部署前满足内部安全要求。BAB检查包括由另一名工程师审核更改的内容、将代码提交到源代码库以及在专用基础架构上以可验证的方式构建二进制文件。在谷歌的基础架构中，BAB限制未经授权的微服务的部署。
主机完整性（HINT）：通过安全引导过程验证主机系统软件的完整性，并基于受支持的安全微控制器硬件运行。主机完整性检查包括在BIOS、BMC、bootloader（引导加载程序）和OS内核上验证数字签名。
服务访问策略（Service Access Policy）和最终用户上下文票据（End user context tickets）用于限制对数据的访问：
服务访问策略：限制服务间数据的访问方式。当RPC从一个服务发送到另一个服务时，服务访问策略会定义访问接收服务的数据所需的身份验证、授权和审核策略。这将限制数据的访问方式，授予所需的最低访问权限级别，以及指定如何审核访问权限。在谷歌的基础架构中，服务访问策略会限制一个微服务访问另一个微服务的数据，并允许对访问控制进行全局分析。
最终用户上下文（EUC）票据：这些票据由最终用户身份认证服务颁发，为服务提供用户身份（不同于服务身份）。这些票据受到完整性保护、集中颁发、支持转发，用于证明请求服务的最终用户身份。这样可以减少服务间的信任需求，因为通过ALTS验证的对等方身份通常不足以授予访问权限，此类授权决策通常也基于最终用户的身份。
用于蓝/绿部署的Borg工具[3]：此工具负责在执行维护任务时迁移正在运行的工作负载。除现有的Borg作业之外，还部署了新的Borg作业，并且负载平衡会逐渐将流量从一个作业迁移到另一个作业。这样就可以在不停机且用户无感知的情况下对微服务进行更新。此工具可以用于在我们添加新功能时应用服务升级，以及在保证不停机的情况下完成关键的安全更新（例如，针对Heartbleed和Spectre/Meltown漏洞的安全更新。对于影响谷歌云基础架构的更改，我们使用实时迁移来确保VM工作负载不受影响。
gVisor，用于工作负载隔离。gVisor使用用户空间内核来拦截和处理系统调用，从而减少了与主机间和潜在的攻击面的交互。此内核提供了运行应用所需的大部分功能，并限制应用可访问的主机内核面。在谷歌的基础架构中，gVisor是用于隔离在同一主机上运行的内部工作负载和谷歌云客户工作负载的几个重要工具之一。
下表2列出了在“安全原则”一节中描述的每个原则与谷歌用于实现该原则的相应工具的对应关系。
表2：谷歌实现云原生安全的原则及安全工具
综合应用
本节将描述前面介绍到的组件是如何组合在一起为云原生环境中的用户请求提供服务的。我们将使用两个例子：第一个，我们追踪从创建到目的地交付的典型用户数据访问请求过程；第二个，我们追踪从开发到投入生产的代码更改过程。请注意，这里将列出的技术不会都用于谷歌基础架构的所有部分——主要取决于服务和工作负载。
用户数据访问
如图1所示，当GFE接收到用户的请求时（步骤1），它会终止TLS连接，并通过ALTS[4]将请求转发到相应的服务前端（步骤2）。应用前端使用中央最终用户身份验证服务（EUA）认证用户的请求，如果认证成功则会接收到一个短期加密的最终用户上下文票据（EUC）（步骤3）。
图1：谷歌云原生架构安全控制措施——用户数据访问
然后，应用前端通过ALTS向存储后端服务发起RPC请求，从而在后端请求中转发EUC票证（步骤4）。后端服务使用服务访问策略来确保：
1.系统授权前端服务的ALTS身份向后端服务发出请求并提供EUC票据，
2.前端的身份由BAB保护，
3.EUC票据有效。
接下来，后端服务检查EUC票据中的用户是否有权访问请求的数据。如果检查中任何一项失败，请求将被拒绝。在很多情况下，存在一系列后端调用，每个中间服务都对入站RPC执行服务访问策略检查，并在出站RPC上转发EUC票据。如果这些检查通过，则数据将返回到授权的应用前端，并提供给授权用户。
每台机器都有一个通过HINT系统预配的ALTS凭据，并且只有在HINT验证计算机引导成功时才能解密。大多数谷歌服务都是运行在Borg上的微服务，这些微服务都有自己的ALTS身份。Borgmaster[5]根据微服务的身份将这些ALTS微服务凭据授予工作负载，如图1所示。机器级的ALTS凭据构建了安全通道来预配置微服务凭据，因此只有成功通过HINT验证引导的机器才能实际托管微服务工作负载。
代码更改
如图2所示，当一个谷歌员工要更改受适当强度BAB保护的微服务时，必须将更改的内容提交到中央代码库执行代码审核。一旦批准，更改的内容将提交到受信任中央构建系统，该系统会生成带有签名的可验证生成清单证书的包（步骤1）。在部署时，BAB通过验证来自构建管道的签名证书来验证此过程（步骤2）。
图2：谷歌云原生架构的安全控制措施——代码更改
无论是常规发布还是紧急安全补丁发布，所有的工作负载更新都是通过蓝/绿部署来处理的（步骤3）。GFE会将流量负载平衡到新部署以确保操作的连续性。
所有工作负载都需要进行隔离。如果工作负载不太可信，例如，工作负载是多租户的，或者源代码来自谷歌外部，可以将其部署到由gVisor保护的环境中，或者使用其他隔离层。隔离可确保在应用的一个实例受到损害时，其他实例都不会受到影响。
应用BeyondProd
全面实施
通过采用云原生架构并有效保护基础架构，谷歌可以为内部和外部（谷歌云）的工作负载都提供非常强大的安全属性。
通过构建共享组件，满足公共安全需求对单个开发人员的负担最小。理想情况下，安全功能不需要集成到每个单独的应用中，而是作为封装和连接所有微服务的结构来提供。这种技术即通常所说的服务网格。这也意味着安全可以与常规开发或部署活动分开管理和实现。
向云原生进行转变
谷歌向云原生的转变要主要在两个方面：在基础架构中和在开发过程中。谷歌在同一时间完成了这两方面更改，但其实它们可以分开并单独完成。
更改基础架构
我们首先构建了服务身份、身份认证和授权的强大基础。有了可信服务身份作基础，就能够实现更高级别的安全功能（如服务访问策略和EUC票据），这些功能依赖于对服务身份的验证。为了使这种转换对于新的和现有的服务都简单，ALTS最初作为仅包含一个助手守护进程的库提供。这个守护进程运行在每个服务都可以调用的主机上，并随着时间的推移演变为使用服务凭据的库。ALTS库被无缝地集成到核心RPC库中——这使它更容易被广泛采用，而不会给各个开发团队带来很大的负担。发布ALTS是发布服务访问策略和EUC票据的前提条件。
更改开发过程
对谷歌来说，建立一个强大的构建和代码审核流程至关重要。这能够确保正在运行的服务的完整性，并确保ALTS使用的身份是有意义的。我们建立了一个集中式的构建流程，在其中能够开始执行要求，如在构建和部署时要求有两人参与代码审核和自动化测试。（如需了解部署的详细信息，参见Borg的二进制授权白皮书。
完成这些基础工作后，就着手开始解决在我们的环境中运行外部的、不可信的代码的需求。为了实现这一目标，我们开始进行沙箱测试——最初使用ptrace，后来使用gVisor。同样的，蓝/绿部署在安全性（例如打补丁）和可靠性方面都提供了显著的优势。
我们很快发现，如果服务一开始选择记录违反策略的行为，而不是直接阻止违反策略的行为，我们的目标会更容易实现。这种方法具有双重优势。首先，它让服务所有者有机会测试更改内容并评估迁移到云原生环境对其服务的影响（若有）。其次，它使我们能够在修复bug的同时找出可能需要向服务团队提供的其他功能。例如，服务登陆到BAB时，服务所有者会启用“仅限审核”模式。这有助于他们识别不符合要求的代码或工作流程。解决了“仅限审核”模式所标记的问题后，服务所有者会启用强制执行模式。在gVisor中，我们首先将工作负载装入沙箱，即使沙箱存在兼容性问题，然后系统地解决这些兼容性问题以改进沙箱，从而达到我们的目的。
转变带来的好处
正如BeyondCorp帮助谷歌超越了基于边界的安全模型一样，BeyondProd在生产环境安全性方面实现了类似飞跃。BeyondProd方法描述了一种云原生安全体系架构，该架构假定服务间不存在信任，隔离工作负载，验证是否仅部署了集中构建的应用，自动执行漏洞管理以及对关键数据实施强访问控制。基于BeyondProd架构，谷歌开发了多个新系统来实现满足这些需求。
太多时候，对安全的考虑总是在最后时刻才被大家想起——这时往往都已经做出了迁移到一个新结构的决定。尽早让安全团队参与进来并且专注于新安全模型的优势，如更简单的补丁管理和更严格的访问控制，云原生架构可以为应用开发和安全团队带来明显的优势。将本文介绍的安全原则应用于诸位读者的云原生基础架构时，可以加强工作负载的部署、保护工作负载的通信方式以及工作负载对其他工作负载的影响。
备注
1.Borg是谷歌的集群管理系统，用于大规模的调度和运行工作负载。Borg是谷歌第一个统一容器管理系统，是Kubernetes的灵感来源。
2.“左移”是指在软件开发生命周期的早期以前执行相关步骤，可能包括代码、构建、测试、验证和部署等步骤。生命周期图表通常是从左到右绘制，所以“左”表示在较前的步骤。
3.蓝/绿部署是一种在不影响传入流量的情况下发布工作负载更改内容的方法，以便最终用户在访问时不会遭遇停机。
4.为了更好地理解流量是如何在谷歌的基础架构中从GFE路由到服务的，请参阅《传输加密》白皮书中的“流量路由方式”部分。
5.Borgmaster是Borg的集中控制器。它负责管理作业的调度，并与正在运行的作业通信。
【需要获得《BeyondProd：一种新的云原生安全方法》英文原文的朋友，请关注本公众号零信任安全社区（izerotrust）并在后台留言"BeyondProd"】
声明：本文来自零信任安全社区，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。
