BeyondProd：云原生安全的一种新方法 | IDCF 来源：云原生技术爱好者社区 作者：BeyondProd Google 此前的几篇白皮书已经介绍我们内部开发的一些增强安全性的项目。从命名来说 ， BeyondProd 是有意让人想起我们先前的另一个概念 BeyondCorp —— 正如边界安全模型 （perimeter security model）不仅不再适用于终端用户（end users）一样，我们将在本 文中论述：边界安全模型同样不再适用于微服务场景。 因此，套用最初 BeyondCorp 中的措辞，我们可以说：“… 本模型的核心假设不再成立：边 界不再仅限于企业的物理位置 [数据中心]，边界内的东西不再是免检的（blessed），边界内 也不再是一个能够安全地存放个人计算设备和企业应用 [微服务]的地方。” 本白皮书介绍 Google 基础设施的多个组件是如何协同工作来保证负载（workload）安全的 —— 我们所使用的架构如今被称为“云原生”（cloud-native）架构。如果想对 Google 安全 有一个整体了解，推荐阅读 Security Infrastructure Design whitepaper。 本文内容截止 2019 年 12 月还是有效的。本白皮书介绍直至本文写作时 BeyondProd 的现 状。Google Cloud 的安全策略和系统可能会随着时间发生变化，正如我们会持续提高 对用 户的安全保护一样。 一、术语（Glossary） 本文将用到以下术语： 微服务（microservice）：微服务将一个应用需要执行的多个独立任务（ individual tasks）拆分为单独的服务（separate services），每个服务都有自己 的 API、独立开 发、维护、发布、扩容和管理配额。 在更加现代的架构中，应用（例如一个网站）是以一系列微服务（a collection of microservices）的形式而非单个单体服务（single monolithic service）的方式运行 的。 微服务是独立的、模块化的、动态的、生命周期较短的（ephemeral）。微服务能够分布 到不同的机器上，不同的集群中，甚至不同的云上。 负载（workload）：一个 workload 就是应用完成的一个特定任务（a unique task that an application completes）。 在微服务架构中，一个 workload 可能是一个或多个微服务。 作业（job）：一个 job 是微服务的一个实例（a single instance of a microservice），执行应用的一部分功能（running some part of an application）。 服务身份（service identity）：在基础设施中，微服务之间使用服务身份做认证。 服务网格（service mesh）：service mesh 是一个服务之间通信（service-to-service communication）的基础设施层（infrastructure layer），能够控制流量、应用策略， 提供中心式的服务调用监控。 微服务引入 service mesh 之后能够降低每个服务的开发负担，因为它们不再需要自己费 力 地实现一遍这些功能；另外，service mesh 还使得微服务之间的管理更加简单，也更加集 中。 二、首席信息官必读（CIO-level summary） Google 基础设施中，每个 workload 都作为独立的微服务部署（deploys workloads as individual microservices），在虚拟化层使用容器，并使用我们的容器编排系统 Borg 来管理这些 workloads。如今火爆业界的“云原生”架构，就是从 Borg 得到灵感，并参考 了其设计。 Google 基础设施在设计时就考虑了安全，而不是事后加的。 我们假设服务之间是无信任的（no trust between services）。 Google 基于名为 BeyondProd 的方案保护微服务安全。该方案包括代码如何变更 ，以及 如何访问微服务内的用户数据。 BeyondProd 应用了如下概念： 双向认证微服务端点（mutually authenticated service endpoints）传输安全 （transport security） 带 GSLB 和 DoS 防护功能的边界终止（edge termination with global load balancing and denial of service protection） 端到端代码来源验证（end-to-end code provenance） 运行时沙盒（runtime sandboxing） 从传统安全模型迁移到云原生安全模型，主要涉及 两方面改动：基础设施和开发流程 （infrastructure and development process） 将共享的组件（components）打造成一个共享的交换网格（fabric），用这个 fabric 将所 有微服务的通信连接起来（enveloping and connecting），即所谓的 service mesh，会 使得发布变更（roll out changes）和获得一致的安全性（ consistent security across services）更加容易。 三、设计动机（Motivation） 出于下面几个原因，我们迁移到了容器和容器编排平台： 获得更高的资源利用率。 构建高可用的应用。 简化 Google 开发者的工作。 此 外 ， 迁 移 到 容 器 化 的 基 础 设 施 还 有 一 个 初 衷 ： 将 安 全 控 制 与 架 构 对 齐 （ align our security controls with our architecture）。 我们已经很清楚地知道，基于边界的安全模型（perimeter-based security model）并非足 够安全。攻击者一旦攻破了边界，就能够在网络内部任意游走。我们意识到需要在基础设 施 中引入更强的安全控制，但也希望这些控制对 Google 开发者是友好的：他们能够轻松地编 写和部署安全的应用，而不用亲自实现安全特性。 从单体应用迁移到容器化的分布式微服务，并基于容器编排系统来编排这些服务，带来了两方 面好处，并且这两方面相互交织： 管理更简单。 可扩展性更好 这种云原生架构需要一种不同的安全模型，以及不同的工具来保护应用部 署，以便与微 服务的管理和扩展性收益相匹配。 本文描述 Google 是如何实现云原生安全（即 BeyondProd）的，包括： 向 云 原 生 的 转 变 ， 对 安 全 意 味 着 什 么 （ what the change to cloud-native means for security）。 云原生安全的安全原则（security principles）。 为满足这些需求所构建的系统。 一些指导原则，基于这些原则你也能构建一套类似的安全控制。 四、Google 的云原生安全 4.1 容器化的微服务 Google 在 初 期 就 有 意 识 地 用 价 格 低 廉 的 普 通 服 务 器 而 非 昂 贵 的 高 可 用 硬 件 构 建 自 己 的 数 据 中心。我们的可靠性指导哲学是 —— 并且将一直是 —— 系统的任何部分都可以发生故障 ， 但不能对用户可见的服务产生影响。 达到这个可用性目标就需要部署冗余实例，这样单个实例挂掉时服务仍然可用。这种哲学的成 果之一是：我们开发了容器、微服务和容器编排系统，以便可扩展地管理这些高冗 余和分布 式系统的部署。 容器化的基础设施意味着，每个 workload 都自成一体，作为一组容器部署，这些容器具有不 可变（immutable）、可移动（moveable）、可调度（scheduleable）的特点。为 了 管 理 这些容器，我们开发了一个称为 Borg [1] 的容器编排系统，现在仍然在使用，每周部署几十 亿个容器。 容 器 的 部 署 方 式 使 得 workload 二 进 制 文 件 打 包 （ bin pack ） 和 在 机 器 间 重 调 度 （ reschedule across machines）更方便。微服务使得开发和调试应用的某个部分更方便。 这 两者结合起来，微服务和容器使得 workloads 能够拆分为更小的、更易维护和发现的单 元。 迁移到基于容器化基础设施的微服务架构， 即如今所谓的向 “云原生” 转变（going “cloudnative”）。服务都运行在容器内，由 Borg 部署。这种架构能根据 workload 大小自动扩缩 容：如果某 个 workload 请求量很大，可能就会扩出多个实例来分担请求。 Google 做 得 比 较 出 色 的 一 点 是 ： 安 全 作 为 重 要 组 成 部 分 ， 在 历 次 架 构 演 进 过 程 中 都 会 考 虑 到。比如我们已经使用多年的保护基础设施安全的 BeyondCorp 模型，以及近 期的云原生安 全（cloud-native security）概念。 采用这种微服务架构和开发流程的目标是：在开发和部署生命周期中，尽量早地解决安全 问 题 —— 越早解决代价越小 ——并且解决安全问题的方式要标准和一致（standardized and consistent）。最终结果是，开发者无需在安全上花太多时间，而仍然能获得更多的安 全性 保证（spend less time on security while still achieving more secure outcomes ）。 4.2 迁移到云原生架构 传统的基于边界的安全模型中，防火墙保护着网络边界，所有用户和服务都位于边界之内并 且是完全受信任的。这种模型已经无法满足现代安全架构（modern security architectures）的需求。 现代企业中，用户的工作方式已经发生了变化，为了应对这种变化，我们之前提出了 BeyondCorp 模型。如今，用户都是移动办公的，工作地点经常会在公司的传统安全边界之 外，例如咖啡厅、飞机上，或者其他任何地方。在 BeyondCorp 中，我们弃用了特权企业 网 络（privileged corporate network）的概念，访问认证（authorized access）只 依赖设 备、用户凭证和属性（device and user credentials and