[譯] BeyondProd:雲原生安全的一種新方法(Google, 2019)

語言: CN / TW / HK

譯者序

本文翻譯自 2019 年 Google 的一篇白皮書 BeyondProd: A new approach to cloud-native security , 介紹了其最新的雲原生安全模型。

Google 雖有官方中文版,但機器翻譯痕跡略重,相比原文反而增加閲讀障礙;故有此拙譯 ,僅供個人學習交流(排版略有調整,以方便網頁閲讀)。

由於譯者水平有限,本文不免存在遺漏或錯誤之處。如有疑問,請查閲原文。

  • 2 首席信息官必讀(CIO-level summary)
  • 3 設計動機(Motivation)
  • 4 Google 的雲原生安全
      • 4.2.1 雲原生和應用部署
      • 4.2.2 給安全工作帶來的啟示(Implications for security)
        • 4.2.2.1 從 “基於邊界的安全”(perimeter-based security)到 “零信任安全”(zero-trust security)
        • 4.2.2.2 從 “固定 IP 和硬件” 到 “更多地共享資源”
        • 4.2.2.3 從 “應用特定的安全實現” 到 “共享的安全需求集成到服務棧中”
        • 4.2.2.4 從 “特定的、頻率較低的發佈流程” 到 “標準化的、頻率更高的發佈流程”
        • 4.2.2.5 從 “物理機或 hypervisor 隔離的 workload” 到 “二進制打包、運行在共享機器上、需要更強隔離性的 workload”
    • 4.3 Google 的內部安全服務
      • 4.4.1 例子:訪問用户數據流程
      • 4.4.2 例子:代碼變更流程
  • 5 BeyondProd 在 Google 的落地
    • 5.1 押寶雲原生(Going all in)
    • 5.2 轉向雲原生,Google 做了什麼

以下是譯文。

Google 此前的幾篇白皮書已經介紹我們內部開發的一些增強安全性的項目。從命名來説 ,BeyondProd 是有意讓人回想起我們先前的另一個概念 BeyondCorp —— 就像 邊界安全 模型 (perimeter security model)不再適用於 終端用户 (end users)一樣,它 也不再適用於 微服務場景 。因此,套用最初 BeyondCorp 論文 中的句子,我們可以説:“… 本模型的核心假設不再成立: 邊界不再僅限於企業的

物理位置

[數據中心],邊界內的東西不再是免檢的(blessed),邊界內也不再 是一個能夠安全地存放

個人計算設備和企業應用 [微服務]的地方

。”

本白皮書介紹 Google 基礎設施的多個組件是如何協同工作來保證負載(workload)安 全的 —— 我們所使用的架構如今被稱為“雲原生”(cloud-native)架構 。如果想對 Google 安全有一個整體瞭解,推薦閲讀 Security Infrastructure Design whitepaper

本文內容截止 2019 年 12 月還是有效的。本白皮書介紹直至本文寫作時 BeyondProd 的 現狀。Google Cloud 的安全策略和系統可能會隨着時間發生變化,正如我們會持續提高 對用户的安全保護一樣。

1 術語(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 還使得微服務之間的管理更加簡單,也更 加集中。

2 首席信息官必讀(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)更加容易。

3 設計動機(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)
  • 為滿足這些需求所構建的系統
  • 一些指導原則,基於這些原則你也能構建一套類似的安全控制

4 Google 的雲原生安全

4.1 容器化的微服務

Google 在初期就有意識地用價格低廉的普通服務器而非昂貴的高可用硬件構建自己的數據 中心。我們的 可靠性指導哲學 是 —— 並且將一直是: 允許系統的任何部分發生故障 ,但不能對用户可見的服務產生影響

達到這個可用性目標就需要部署宂餘實例,這樣單個實例掛掉時服務仍然可用。 這種哲學 的成果之一是:我們開發了容器、微服務和容器編排系統 ,以便可擴展地管理這些高宂 餘和分佈式系統的部署。

容器化的基礎設施意味着,每個 workload 都自成一體,作為一組容器部署,這些容器具有 不可變(immutable)、可移動(moveable)、可調度(scheduleable)的特點。為了管理 這些容器,我們開發了一個稱為 Borg [1] 的容器編排系統,現在我們仍然在使用,每週部署幾十億個容器。

容器的部署方式使得 workload 二進制文件打包(bin pack)和在機器間重調度( reschedule across machines)更方便。微服務使得開發和調試應用的某個部分更方便。這 兩者結合起來,微服務和容器使得 workloads 能夠拆分為更小的、更易維護和發現的單元。

遷移到基於容器化基礎設施的微服務架構, 即如今所謂的 “雲原生” 轉變 (going “cloud-native”)。 服務都運行在容器內,由 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 attributes),而 不 關心用户(接入時)的網絡位置 (network location)。

雲原生安全的理念與此類似,只不過關注點從 用户(users) 變成了 服務(services ) —— 在雲原生世界裏,我們不能僅簡單地依賴防火牆來保護生產網絡(production network),正如我們不能依賴防火牆保護企業網絡(corporate network)。

進一步,我們可以做如下對比:

  • 企業網絡中 :不同的用户可能 從不同的物理位置、通過不同的設備訪問企業網絡
  • 生產網絡中 :不同的開發者可能會 將應用發佈到不同的生產環境 。在 BeyondProd 模型中,微服務可能會運行在有防火牆保護的數據中心、公有云、私有云, 或者第三方託管的服務商,而這些環境都是需要安全保護的。

另外,

  • 企業網絡中 :用户會移動,使用不同設備,從不同位置接入。
  • 生產網絡中 :微服務會移動,部署在不同環境中,跨異構機器(heterogeneous hosts)。

BeyondCorp 中提到,

用户信任 (user trust)應依據 設備的可感知上下文的狀態 等信息,而不應依 據能否連接到企業網絡”。

” should be dependent on characteristics like the context-aware state of devices and not the ability to connect to the corp network”

類似地理念在 BeyondProd 中表述為,

服務信任 (service trust)應依據 代碼來源和服務身份 等信息,而不應依據在 生產網絡中的位置,例如 IP 或 hostname identity”。

“service trust should be dependent on characteristics like code provenance and service identity, not the location in the production network, such as IP or hostname identity”.

4.2.1 雲原生和應用部署

偏傳統的安全模型主要關注基於邊界的安全(perimeter-based security),只靠這種模型 不足以保護雲原生架構的安全。

考慮下面這個例子:

  • 單體應用
  • 部署在私有的企業數據中心
  • 數據中心採用傳統“接入-匯聚-核心”三級網絡架構(three-tier architecture)
  • 應用和物理資源都有足夠的容量,能抗住突發事件的峯值負載

這種有特殊硬件和網絡需求的應用,都會特意部署到特殊的機器,通常情況下,這些機器都 有固定的 IP 地址。在這種情況下,應用的

  • 發佈頻率很低
  • 發佈很費勁
  • 很難協調,因為變更會同時影響應用的不同部分
  • 導致應用難以更新,輕易不更新,安全補丁也不能及時打上去

如果是雲原生模型,情況就不同了:

  • 容器將應用的可執行文件與底層的宿主機操作系統解耦,使得應用更易漂移(more portable)。
  • 容器的設計使用方式是不可變(be used immutably),這意味着一旦部署容器就不會再 變 —— 因此容器的重新構建和重新部署(rebuilt and redeployed)會更加頻繁。
  • Jobs 可根據負載大小靈活擴展(scaled to handle load),負載升高時部署新 jobs, 負載降下去之後部分 jobs 銷燬。
  • 容器經常會重啟、銷燬或重新調度,因此有硬件和網絡的再利用和共享率更高。
  • 基於標準的構建和分發流程(build and distribution process),即使多個團隊獨立管 理他們的微服務開發,團隊之間的開發過程也會更加一致和統一。
  • 最終結果:能在開發過程中的更早階段開始考慮安全方面的問題 (例如,安全評審 、代碼掃描、漏洞管理)。

4.2.2 給安全工作帶來的啟示(Implications for security)

我們已經討論了很多邊界內部非受信(untrusted interior)的情況,即 BeyondCorp 中的 用户,也適用於 BeyondProd 中的微服務 —— 但這需要安全做出哪些變化?表 1 列出了傳 統基礎設施安全和雲原生架構安全的對比。表中還給出了從前者遷移後者需要做哪些事情。

表 1:遷移到雲原生架構面臨的安全需求

傳統基礎設施安全 雲原生安全 安全需求
基於邊界的安全(例如防火牆),認為邊界內可信 零信任安全,服務到服務通信需認證,環境內的服務之間默認沒有信任 保護網絡邊界(仍然有效);服務之間默認沒有互信
應用的 IP 和硬件(機器)固定 資源利用率、重用、共享更好,包括 IP 和硬件 受信任的機器運行來源已知的代碼
基於 IP 的身份 基於服務的身份 同上
服務運行在已知的、可預期的位置 服務可運行在環境中的任何地方,包括私有云/公有云混合部署 同上
安全相關的需求由應用來實現,每個應用單獨實現 共享的安全需求,集成到服務中,集中地實施策略(enforcement policy) 集中策略實施點(choke points),一致地應用到所有服務
對服務如何構建和評審實施的限制較少 安全相關的需求一致地應用到所以服務 同上
安全組件的可觀測性較弱 有安全策略及其是否生效的全局視圖 同上
發佈不標準,發佈頻率較低 標準化的構建和發佈流程,每個微服務變更獨立,變更更頻繁 簡單、自動、標準化的變更發佈流程
部署在虛擬機或物理機上,用物理機或 hypervisor 做隔離 二進制打包到容器鏡像,運行在共享的操作系統上,需要 workload 隔離機制 在共享操作系統的 workload 之間做隔離

接下來對以上表格做一些解釋。

4.2.2.1 從 “基於邊界的安全”(perimeter-based security)到 “零信任安全”(zero-trust security)

在傳統安全模型中,應用可以依賴私有數據中心的邊界防火牆對入向流量做安全防護。

在雲原生安全模型中,邊界防火牆仍然必要,正如在 BeyondCorp 模型中一樣,但單靠防火 牆已經不夠了。

這裏並沒有引入新的待解決的安全問題,而是意識到這樣一個事實:如果單靠防火牆無法完 全保護企業網絡(corporate network),那單靠防火牆同樣不能完全保護生產網絡( production network)。

在零信任安全模型中,內部流量之間默認不再有信任 —— 需要其他的安全控制,例如認證和 加密。同時, 向微服務的轉變提供了一個對傳統安全模型進行重新思考的機會

  1. 去掉僅僅依賴網絡邊界(例如,防火牆)這一假設後 ,就可以 按服務(service)對網絡進行進一步劃分
  2. 順着這個思路,更進一步,可以實現 微服務級別的隔離 (microservice-level segmentation),而 服務之間無固有的信任 (no inherent trust between services)。
  3. 在這種微服務架構下, 流量會有不同層次的信任,每層都有不同的控制方式 —— 而 不再僅僅依據是內部流量還是外部流量來做區分。

4.2.2.2 從 “固定 IP 和硬件” 到 “更多地共享資源”

在傳統安全模型中,應用都是部署到特定的機器上,這些機器的 IP 地址很少發生變化。這 意味着安全工具看到的是一個 相對靜態的架構地圖 (architecture map),其中的應用 都是以可預知的方式聯繫到一起的 —— 因此防火牆這類的工具中,安全策略可以用 IP 地址 作為標識符(identifiers)。

但是,在雲原生世界中,隨着共享宿主機和變化頻繁的 jobs,使用防火牆控制微服務間的 訪問變得不可行。我們不能再假設一個特定的 IP 地址會對應到一個特定的服務。因此, 身份應該基於服務,而不是 IP 地址或主機名(hostname)

4.2.2.3 從 “應用特定的安全實現” 到 “共享的安全需求集成到服務棧中”

在傳統安全模型中,每個應用負責實現自己的安全需求,與其他服務的安全實現完全獨立。 這些安全需求包括:

  • 身份管理(identity management)
  • SSL/TLS termination
  • 數據訪問管理(data access management)

這種方式會導致不一致的實現,或者未能全局地解決某些安全問題,因為這些問題遍佈在多 個地方,修復更加困難。

在雲原生世界中,服務之間重用(reuse)組件的頻率更高,並且有 中心式的安全策略實 施點 (choke points),使得各服務的策略實施更加一致。可以使用不同的安全服務實施 不同的安全策略。此時每個應用不再需要自己實現關鍵的安全服務,你可以將這些安全策略 應用到獨立的微服務(例如,一種策略用於保障用户數據的授權訪問,另一種策略用於保證 使用了最新的 TLS 加密套件)。

4.2.2.4 從 “特定的、頻率較低的發佈流程” 到 “標準化的、頻率更高的發佈流程”

傳統安全模型中,共享的服務非常少。代碼(在整個應用內)更加分散,與本地開發( local development)的耦合更高,這意味着如果一個變更會影響到應用的多個部分,我們 很難估計它可能導致的影響 —— 結果,發佈頻率變低,很難協調發布流程。在變更的時候, 開發者可能需要直接更新每個組件(例如,SSH 到虛擬機,更新某個配置)。綜合起來,這 導致 線上存在很多壽命極長的應用(extremely long-lived applications)(的實例)

從安全的角度看,由於代碼(在整個應用內)更加分散,因此更難 review;如果發現一個 漏洞,要確保這個漏洞在所有代碼中都修復了甚至更加困難。

遷移到頻率更高、更加標準化的雲原生髮布後, 安全在軟件開發生命週期的位置就能夠左 移 [2]。這使得實現一致的安全策略實施(包括常規的安裝安全補丁)更加簡單。

4.2.2.5 從 “物理機或 hypervisor 隔離的 workload” 到 “二進制打包、運行在共享機器上、需要更強隔離性的 workload”

傳統安全模型中,workloads 都是調度到各自專屬的實例上,不存在共享資源,因此 機器 和網絡邊界能夠有效地保護機器上的應用 ;另一方面,物理機器、hypervisor 和傳統防 火牆也能夠有效地隔離 workload。

在雲原生世界中,workloads 都是容器化的,可執行文件打包到容器鏡像,然後調度到共享 資源的機器上執行。因此,workload 之間需要有更強的隔離機制。通過網絡控制、sandbox 之類的技術,能夠部分地將 workload 隔離到不同的微服務。

4.2.3 安全原則

在設計雲原生架構的過程中,我們希望在多個方面同時加固我們的安全(concurrently strengthen our security) —— 因此我們制定和優化了下面的這些安全原則:

  • 在邊界保護網絡:能夠在網絡攻擊和來自公網的未授權流量面前保護 workload。

    雖然基於防火牆的方法對雲原生來説並不是一個新概念,但它 仍然是一條最佳安全 實踐 。在雲原生環境中,邊界方式(perimeter approach)用於 最大程度地在來自 公網的未授權流量和潛在攻擊(例如,大規模 DoS 攻擊)面前保護基礎設施

  • 服務之間默認沒有互信:因此,只有已知的、受信的、認證過的調用方才能訪問服務。

    這能防止攻擊者利用未受信的代碼(untrusted code)訪問服務。如果一個服務被攻陷 了,這個服務能夠阻止攻擊者執行能擴展其訪問範圍的動作。 這種雙向非互信( mutual distrust)有助於限制被入侵時的爆炸半徑

  • 受信的機器運行來源已知的代碼:這樣就限制了服務只能使用認證過的代碼和配置, 並且只能運行在認證過的、驗證過的環境中。

  • 在 Choke points 對所有服務實施一致的策略。

    例如,在 choke point 驗證訪問用户數據的請求,服務訪問權限從已授權終端用户的 已驗證請求中推導(derived from a validated request from an authorized end user),管理員訪問權限申請需要證明有業務必要(business justification)。

  • 簡單、自動化、標準化的發佈變更流程:更容易評審基礎設施的變更對安全的影 響;更新安全補丁對線上業務幾乎沒有影響。

  • 在共享操作系統的 workloads 之間做隔離:一個服務被入侵後,不會影響同宿 主機上其他服務的安全。這限制了潛在入侵後的“爆炸半徑”。

我們的 最終目標 是:實現整個基礎設施之上的自動化安全控制,不依賴人工參與。

  • 安全應當能以 與服務一樣的方式進行擴展
  • 對於服務來説, 安全是日常,不安全是例外 (secure by default and insecure by exception)。
  • 人工干預應當是例外,而不是日常 ,並且 人工干預的過程應當是可審計的
  • 最終我們能夠 基於服務部署時的代碼和配置對服務進行認證 ,而不是基於對部署這個服務的人。

綜上,這些安全原則的實現意味着,容器和其內運行的微服務應該是可部署的、能夠與彼此 通信的、共享資源的,且不會削弱雲原生架構的優良特性(例如,簡單的 workload 管理、 自動擴縮容、高效的可執行文件打包)。在不給微服務開發者增加負擔、無需他們了 解底層基礎設施的安全和實現細節的前提下,這些目標仍然是可實現的。

4.3 Google 的內部安全服務

為保護 Google 的雲原生基礎設施,我們設計和開發了一些內部工具和服務。下面列出的這 些工具和服務協同工作,實現了前面定義的安全原則。

  • Google Front End (GFE) : 終結來自終端用户的連接,提供一個集中實施 TLS 最佳實踐的位置(central point for enforcing TLS best practices)。

    雖然我們的重心已經不再是基於邊界的安全,但 GFE 仍然是我們保護內部服務免受 DoS 攻擊的安全策略重要組成部分。

    GFE 外側是用户連接到達 Google 後的第一個位置點;內側負責將流量負載均衡和重路由( rerouting)到合適的 region。在我們的基礎設施中,GFE 是邊緣代理,將流量路由到正 確的微服務。

  • Application Layer Transport Security (ALTS,應用層傳輸安全) : 用於 RPC 認證、完整性驗證和加密。

    ALTS 是 Google 基礎設施中服務間的一個 雙向認證和傳輸加密 系統。身份( identities)通常與服務(services )綁定,而不是與服務器名字或宿主機(server name or host)綁定。這使得無縫的微服務複製、負載均衡和跨宿主機重調度更加方便。

  • Binary Authorization(二進制授權)for Borgand Host Integrity :分別用 於微服務和機器的完整性驗證。

    • Binary Authorization for Borg (BAB,Borg 二進制授權) : 一種部署時檢查(deploy-time enforcement check)機制,確保代碼在部署之前符 合內部安全要求。BAB 檢查包括由其他工程師 review 過的變更、提交到倉庫的 代碼、在專屬基礎設施上構建出來的可驗證二進制文件。在我們的基礎設施中, BAB 防止了未授權微服務的部署

    • Host Integrity (HINT,宿主機完整性):通過一個安全的啟動過程,驗證宿主 機系統軟件的完整性,由安全的微控制器硬件在背後支持(secure microcontroller hardware)。HINT 檢查包括 驗證 BIOS、BMC、Bootloader 和操作系統內核 的數字簽名。

  • Service Access Policy和 End user context tickets :用於限制對數據的訪問。

    • Service Access Policy (服務訪問策略) : 限制服務之間的數據訪問。當從一個服務向另一個服務發起 RPC 調用時, Service Access Policy 會定義訪問對端服務的數據時所需的認證、鑑權和審計策略。 這會限制數據訪問方式、授予最小級別的訪問權限,並規定這種訪問應當如何審計。 在 Google 基礎設施中, Service Access Policy 限制了一個微服務對另一方 微服務的數據的訪問,並支持訪問控制的全局分析

    • End user context (EUC,終端用户上下文) tickets : 這些 tickets 由 End User Authentication service(終端用户認證服務)頒發, 給每個服務提供一個用户身份 (user identity),這個身份與他們的服務身份(service identity)是獨立的 。 這些 tickets 是有完整性保護的(integrity-protected),中心式頒發的(centrally-issued), 可轉發的憑證(forwardable credentials),能夠證明某個正在請求服務的終端用户的身份。 這使得服務之間不需要彼此信任, 基於 ALTS 的對端身份(peer identity via ALTS)經常不足以完成授權,因為這種授權決定通常還要基於終端用户的身份

  • 用於藍綠部署的 Borg 工具集[3]:在執行維護任務時,這種工具負責對運行中的 workloads 進行遷移。

    方式:現有的 Borg job 不動,加入一個新 Borg job,然後負載均衡器將流量逐步從 前者切到後者。

    這種方式使得升級微服務時不會引起服務中斷(downtime),終端用 户無感知。

    這種工具用於無間斷地服務升級(服務添加了新特性),以及重要安全更新(例如 HeartBleed 和 Spectre/Meltdown )。如果變更會影響到 Google Cloud 基礎設施,我們會使用熱遷移(live migration) 保證虛擬機 workload 不受影響。

  • gVisor :用於 workload 隔離。

    gVisor 使用一個用户態內核攔截和處理系統調用,減少與宿主機的交互以及潛在的攻 擊面。這個內核提供了運行一個應用所需的大部分功能,但縮小了應用能夠訪問到的宿 主機內核表面(host kernel surface)。

    在 Google 的基礎設施中,內部應用和 Google Cloud 客户的應用共享宿主機,而 gVisor 就是我們隔離二者的重要工具之一。

表 2 列出了 Google 基礎設施中,前面提到的各種安全原則所對應的工具。

表 2:安全原則和對應的 Google 內部工具

安全原則 Google 內部安全工具/服務
在網絡邊界做防護 GFE:管理 TLS termination 以及入向流量策略
服務間無內在的互信 ALTS:用於 RPC 認證、完整性檢查、加密和服務身份
受信的機器運行來源已知的代碼 BAB:代碼來源驗證。HINT:機器完整性驗證
在 choke points 對所有服務實施一致的策略 Service Access Policy:限制服務間如何訪問數據。EUC ticket:證明初始請求者(original requester)的身份
簡單、自動、標準化的變更發佈 Borg tooling:藍綠部署
隔離共享操作系統的 workloads gVisor

4.4 綜合到一起

本節描述在雲原生世界中,前面討論的各組件如何組織到一起,響應終端用户的請求。 這裏我們看兩個例子:

  1. 跟蹤一個典型的用户數據請求,從其創建到請求到達目的地
  2. 跟蹤一次代碼變更,從開發直至發佈到生產環境

需要説明的是,這裏列出的技術並不是都會用於 Google 基礎設施中的每個部分,具體 用到哪些取決於服務和 workloads。

4.4.1 例子:訪問用户數據流程

Fig 1. Google 雲原生架構安全控制 —— 訪問用户數據

如圖 1 所示,

  1. GFE 收到用户請求
  2. GFE 終止 TLS 連接,通過 ALTS [4] 將請求轉發給合適的服務前端(service’s frontend)
  3. 應用前端使用一箇中心式的 End User Authentication (EUA) 服務對用户請求進行認證 ,如果成功,會得到一個短期有效的、加密的 end user context ticket (EUC)
  4. 應用前端在請求中帶上 EUC ticket,然後通過 ALTS 向存儲後端服務發起 RPC 請求。

後端服務通過 Service Access Policy 來保證:

  1. 前端服務的 ALTS 身份是經過授權的,允許向後端服務發起請求,並且帶了 EUC ticket。
  2. 前端的身份已經受 Binary Authorization for Borg (BAB) 保護。
  3. 請求中所帶的 EUC ticket 是合法的。後端服務檢查用户的 EUC ticket 是經過授權的 ,才允許訪問其所請求的數據。

以上任何一步檢查失敗了,請求就會被拒絕。

很多情況下,後端調用形成一個調用鏈, 每個中間服務都會在入向(inbound)RPC 執行 Service Access Policy 檢查,並在出向(outbound)RPC 中帶上 EUC ticket

如果這些檢查都通過了,數據就會返回給已授權的應用前端,後者再轉發給已授權的用户。

機器和微服務 ALTS 憑證:

  • 每個機器都有一個由 HINT 系統頒發的 ALTS 憑證 ,只有 HINT 驗證過這台機器啟動 是正常的(machine boot was successful),這個 ALTS 憑證才能被解密。
  • 大部分 Google服務都以微服務的方式運行在 Borg 上,這些 微服務都有各自的 ALTS身份
  • Borgmaster [5] 基於微服務的身份向 workloads 授予 ALTS 微服務憑證 ,如圖 1 所示。
  • 機器級別的 ALTS憑證成為了 提供微服務憑證的安全通道 (secure channel for provisioning microservice credentials),因此實際上只有成功地通過了 HINT 檢查 的機器才能運行微服務 workloads。

4.4.2 例子:代碼變更流程

Fig 2. Google 雲原生架構安全控制 —— 代碼變更

如圖 2 所示,

  1. 開發者修改了某個微服務,這些變動必須提交到我們的中心式代碼倉庫進行 code review。
  2. code review 通過之後,變更會提交到一箇中心式的、受信任的構建系統,後 者會產生一個包(package),這個 package 附帶了一個經過簽名的、可驗證的 build manifest 證書。在部署時(deployment time),BAB 會對已簽名的證書進行驗證。
  3. 所有 workload 更新(不管是例行更新,還是緊急安全補丁)都以藍綠部署方式進行。 GFE 通過負載均衡將流量切換到新部署的版本上,保證業務的連續。

所有的 workloads 都需要隔離。如果 workload 可信程度較低,例如,是多租户 workload 或源代碼來自 Google 之外,這種 workload 可能會被部署到 gVisor 保護的環 境中,或者利用其它層的隔離。如果應用的一個實例被入侵了,這種隔離能保證其它的實例 不受影響。

5 BeyondProd 在 Google 的落地

5.1 押寶雲原生(Going all in)

向雲原生的轉變,再加上基礎設施之上的合理安全措施,使得 Google 能夠提供非常強的安 全特性,這包括我們的內部 workloads ,也包括外部(Google Clod)workloads。

通過構建共享的組件,每個開發者自己需要實現的公共安全需求降到了最低。

理想情況下,安全功能只應該有很少部分(甚至完全不應該)集成到每個應用中,而應該作 為一個底層的交換網格(fabric)連接各微服務。這種架構通常稱為 service mesh。這同 時也意味着, 安全能夠從常規的開發或部署活動中獨立出來,單獨管理和實現

5.2 轉向雲原生,Google 做了什麼

Google 向雲原生的轉變主要涉及兩個方面的改造工作:

  1. 基礎設施
  2. 開發流程

我們是同時對這兩方面做出調整的,但二者是可以解耦的,也可以針對二者分別做改造。

5.2.1 改造基礎設施

我們首先構建了一個非常強大的提供服務身份、認證和鑑權的基礎平台。

有了這樣一個受信的服務身份平台,我們就能實現更高層的安全能力,這些高層能力依賴 服務身份做驗證,例如 Service Access Policies 和 EUC tickets。

為使轉變過程對新服務和老服務都比較簡單平滑,ALTS 最開始是以函數庫加輔助守護進程(a library with a single helper daemon) 的方式提供的。

  • daemon 運行在宿主機上,會被每個服務調用,隨着時間推移,演進成一個使用服務憑證 (a library using service credentials)的函數庫。
  • ALTS 庫無縫集成到核心 RPC 庫 —— 這大大方便了其被應用接入(gain wide adoption) ,而且不會給每個開發團隊增加顯著負擔。

ALTS 是 Service Access Policies 和 EUC tickets 的前提,必須先於二者落地。

5.2.2 改造開發流程

打造一個 健壯的構建和 code review 流程對 Google 至關重要 。有了這些我們才能 確保運行中服務的完整性,以及 ALTS 使用的身份是有意義的

我們實現了一箇中心式的構建流程,在這裏能夠實施一些安全策略,例如在構建和部署時, 執行雙人 code review 和自動化測試。(更多部署相關的細節,見 Binary Authorization for Borg whitepaper

有了這些基礎之後,開始嘗試在我們的環境中運行外部非受信代碼。為此,我們使 用了沙盒(sandboxing)—— 最初用 ptrace,後來切換到 gVisor。類似地,藍綠部署給安 全提供了顯著便利(例如安全補丁),並增強了可靠性。

在初期,我們很快意識到這樣一點: 服務的安全驗證失敗時,不應直接拒絕,而應打印出 驗證失敗的策略日誌 (logging policy violations rather than blocking violations )。這能夠帶來兩方面好處:

  1. 將服務遷移到雲原生環境的過程中,給了服務的 owner 一個測試代碼改動和評估對其服 務影響的機會
  2. 使得我們能及時修 bug,以及識別應當提供給服務團隊哪些額外功能

例如,當一個服務新接入 BAB 時,服務 owner 會打開 audit-only 模式。這有助於 識別出不符合要求的代碼和工作流。一旦解決了發現的這些問題,他們就可以關閉 audit-only 模式,切換到 enforcement 模式。

我們會先使用 gVisor 對 workloads進行沙盒測試,即使沙盒提供的能力和我們的需求之間 仍有差距,我們會不斷找出這些差距,逐步增強沙盒的功能。

5.3 帶來的收益

正如 BeyondCorp 幫助我們邁過了基於邊界的安全模型時代,BeyondProd 也代表了一個類 似的飛躍:這次解決的是生產環境的安全問題。

BeyondProd 方法描述了一個雲原生安全架構,其:

  • 假設服務之間沒有信任
  • 提供了 workload 之間的隔離
  • 部署時驗證,只有合法平台構建出來的應用(centrally built applications)才允許部署
  • 自動化漏洞管理
  • 對核心數據執行強訪問控制

BeyondProd 架構促使 Google 研發了幾個新系統來滿足這些需求。

實際中,我們經常看到 安全總是在最後時刻才被人們記起 (security is ‘called in’ last)——在遷移到新架構的決定已經做出之後。更早地讓你們的安全團隊參與進來,並且關 注於新的安全模型帶來的收益,例如更簡單的補丁管理和更強的訪問控制,雲原生架構就能 為應用研發團隊和安全團隊帶來巨大收益。

將本文描述的安全原則應用到你們的基礎設施中,就能增強 workloads 的部署、 workloads 之間的通信安全,以及 workloads 之間的隔離性。

6. 注

  1. Borg is Google’s cluster management system for scheduling and running workloads at scale. Borg was Google’s first unified container management system , and the inspiration for Kubernetes .
  2. “Shifting left” refers to moving steps earlier in the software development lifecycle, which may include steps like code, build, test, validate, and deploy. Lifecycle diagrams are frequently drawn from left to right, so left means at an earlier step.
  3. A blue/green deployment is a way to roll out a change to a workload without affecting incoming traffic, so that end users don’t experience any downtime in accessing the application.
  4. To better understand how traffic is routed inside Google’s infrastructure from the GFE to a service, see the How traffic gets routed section of our Encryption in Transit whitepaper.
  5. Borgmaster is Borg ’s centralized controller. It manages scheduling of jobs, and communicates with running jobs on their status.