作者：
楊甯，花名麟童，阿裡雲基礎産品事業部進階安全專家
劉梓溪，花名寞白，螞蟻金服大安全基礎安全安全專家
李婷婷，花名鴻杉，螞蟻金服大安全基礎安全資深安全專家
簡介
零信任安全最早由著名研究機構 Forrester 的首席分析師約翰.金德維格在 2010 年提出。零信任安全針對傳統邊界安全架構思想進行了重新評估和審視，并對安全架構思路給出了新的建議。
其核心思想是，預設情況下不應該信任網絡内部和外部的任何人/裝置/系統，需要基于認證和授權重構通路控制的信任基礎。諸如 IP 位址、主機、地理位置、所處網絡等均不能作為可信的憑證。零信任對通路控制進行了範式上的颠覆，引導安全體系架構從“網絡中心化”走向“身份中心化”，其本質訴求是以身份為中心進行通路控制。
目前落地零信任概念包括 Google BeyondCorp、Google ALTS、Azure Zero Trust Framework 等，雲上零信任體系，目前還是一個新興的技術趨勢方向，同樣的零信任模型也同樣适用于 Kubernetes，本文重點講解一下 Kubernetes 下零信任安全架構的技術分析。
傳統零信任概念和目前落地情況
Microsoft Azure
Azure 的零信任相對來說還是比較完善的，從體系角度來看涵蓋了端、雲、On-Permises、SaaS 等應用，下面我們分析一下相關的元件：
- 使用者 Identity：然後通過 Identity Provider（建立、維護和管理使用者身份的元件）的認證，再認證的過程中可以使用賬号密碼，也可以使用 MFA（Multi Factor Auth）多因素認證的方式，多因素認證包括軟、硬 Token、SMS、人體特征等；
- 裝置 Identity：裝置包含了公司的裝置以及沒有統一管理的裝置，這些裝置的資訊，包含 IP 位址、MAC 位址、安裝的軟體、作業系統版本、更新檔狀态等存儲到 Device Inventory；另外裝置也會有相應的 Identity 來證明裝置的身份；裝置會有對應的裝置狀态、裝置的風險進行判定；
- Security Policy Enforcement：通過收集的使用者 Identity 以及狀态、裝置的資訊，狀态以及 Identity 後，SPE 政策進行綜合的判定，同時可以結合 Threat Intelligence 來增強 SPE 的政策判定的範圍和準備性；政策的例子包括可以通路後面的 Data、Apps、Infrastructure、Network；
- Data：針對資料（Emails、Documents）進行分類、标簽、加密的政策；
- Apps：可以自适應通路對應的 SaaS 應用和 On-Permises 應用；
- Infrastructure：包括 IaaS、PaaS、Container、Serverless 以及 JIT（按需開啟通路）和 GIT 版本控制軟體；
- Network：針對網絡傳遞過程以及内部的微隔離進行政策打通。
下面這張微軟的圖進行了更加細化的講解，使用者（員工、合作夥伴、使用者等）包括 Azure AD、ADFS、MSA、Google ID 等，裝置（可信的合規裝置）包括 Android、iOS、MacOS、Windows、Windows Defender ATP，用戶端（用戶端 APP 以及認證方式）包括浏覽器以及用戶端應用，位置（實體和虛拟位址）包括位址位置資訊、公司網絡等，利用 Microsoft 的機器學習 ML、實時評估引擎、政策等進行針對使用者、用戶端、位置和裝置進行綜合判定，來持續自适應的通路 On-Permises、Cloud SaaS Apps、Microsoft Cloud，包含的政策包括 Allow、Deny，限制通路、開啟 MFA、強制密碼重置、阻止和鎖定非法認證等；從下圖可以看出 Azure 已經打通了 On-Permises、Cloud、SaaS 等各個層面，建構了一個大而全的零信任體系。
Google BeyondCorp
Google BeyondCorp 是為了應對新型網絡威脅的一種網絡安全解決方案，其實 Google BeyondCorp 本身并沒有太多的技術上的更新換代，而是利用了持續驗證的一種思路來做的，去掉了 VPN 和不再分内外網。Google 在 2014 年之前就預測到網際網路和内網的安全性是一樣危險的，因為一旦内網邊界被突破的話，攻擊者就很容易的通路企業的一些内部應用，由于安全意識的問題導緻企業會認為我的内部很安全，我就對内部的應用進行低優先級别的處理，導緻大量内部的安全問題存在。現在的企業越來越多的應用移動和雲技術，導緻邊界保護越來越難。是以 Google 幹脆一視同仁，不分内外部，用一樣的安全手段去防禦。
從攻防角度來看一下 Google 的 BeyondCorp 模型，例如通路 Google 内部應用
http://blackberry.corp.google.com，它會跳轉到
https://login.corp.google.com/也就是 Google Moma 系統，首先需要輸入賬号密碼才能登陸，這個登入的過程中會針對裝置資訊、使用者資訊進行綜合判定，賬号密碼正确以及裝置資訊通過規則引擎驗證之後，會繼續跳轉到需要 YubiKey 登入界面，每個 Google 的員工都會有 Yubikey，通過 Yubikey 來做二次驗證。Yubikey 的價值，Google 認為是可以完全杜絕釣魚攻擊的。另外類似的就是 Amazon 的
Midway-Auth 方式（
https://midway-auth.amazon.com/login?next=%2F）。
Kubernetes 下容器零信任模型
容器下網絡零信任
首先介紹一下容器下的網絡零信任元件 Calico，Calico 是針對容器，虛拟機和基于主機的本機 Workload 的開源網絡和網絡安全解決方案産品。Calico 支援廣泛的平台，包括 Kubernetes、OpenShift、Docker EE、OpenStack 和裸金屬服務。零信任最大的價值就是即使攻擊者通過其他各種手法破壞應用程式或基礎架構，零信任網絡也具有彈性。零信任架構使得使攻擊者難以橫向移動，針對性的踩點活動也更容易發現。
在容器網絡零信任體系下，Calico+Istio 目前是比較熱的一套解決方案；先來看看兩者的一些差别，從差别上可以看到 Istio 是針對 Pod 層 Workload 的通路控制，以及 Calico 針對 Node 層的通路控制：
| Istio | Calico | |
|---|---|---|
| Layer | L3-L7 | L3-L4 |
| 實作方式 | 使用者态 | 核心态 |
| 政策執行點 | Pod | Node |
下面重點講解一下 Calico 元件和 Istio 的一些技術細節，Calico 建構了一個 3 層可路由網絡，通過 Calico 的 Felix（是運作在 Node 的守護程式，它在每個 Node 資源上運作。Felix 負責編制路由和 ACL 規則以及在該 Node 主機上所需的任何其他内容，以便為該主機上的資源正常運作提供所需的網絡連接配接）運作在每個 Node 上，主要做路由和 ACL 的政策以及搭建網絡；通過運作在 Node 上的 Iptables 進行細粒度的通路控制。可以通過 Calico 設定預設 Deny 的政策，然後通過自适應的通路控制來進行最小化的通路控制政策的執行，進而建構容器下的零信任體系；Dikastes/Envoy：可選的 Kubernetes sidecars，可以通過互相 TLS 身份驗證保護 Workload 到 Workload 的通信，并增加相關的控制政策；
再講解 Istio 之前先講一下微服務的一些安全需求和風險分析：
1、微服務被突破之後通過 Sniffer 監控流量，進而進行中間人攻擊，為了解決這種風險需要對流量進行加密；
2、為了針對微服務和微服務之間的通路控制，需要雙向 TLS 和細粒度的通路政策；
3、要稽核誰在什麼時候做了什麼，需要審計工具；
分析了對應的風險之後，下面來解釋一下 Istio 如何實作的零信任架構。首先很明顯的一個特點就是全鍊路都是雙向 mTLS 進行加密的，第二個特點就是微服務和微服務之間的通路也可以進行鑒權，通過權限通路之後還需要進行審計。Istio 是資料面和控制面進行分離的，控制面是通過 Pilot 将授權政策和安全命名資訊分發給 Envoy，然後資料面通過 Envoy 來進行微服務的通信。在每個微服務的 Workload 上都會部署 Envoy，每個 Envoy 代理都運作一個授權引擎，該引擎在運作時授權請求。當請求到達代理時，授權引擎根據目前授權政策評估請求上下文，并傳回授權結果 ALLOW 或 DENY。
微服務下的 Zero Trust API 安全
42Crunch（
https://42crunch.com/）将 API 安全從企業邊緣擴充到了每個單獨的微服務，并通過可大規模部署的超低延遲微 API 防火牆來進行保護。 42Crunch API 防火牆的部署模式是以 Kubernetes Pod 中以 Sidecar 代理模式部署，毫秒級别的性能響應。 這省去了編寫和維護單個 API 安全政策過程，并實施了零信任安全體系結構，提升了微服務下的 API 安全性。42Crunch 的 API 安全能力包括：稽核：運作 200 多個 OpenAPI 規範定義的安全稽核測試，并進行詳細的安全評分，以幫助開發人員定義和加強 API 安全；掃描：掃描實時 API 端點，以發現潛在的漏洞；保護：保護 API 并在應用上部署輕量級，低延遲 Micro API Firewall。
螞蟻零信任架構體系落地最佳實踐
随着 Service Mesh 架構的演進，螞蟻已經開始在内部落地 Workload 場景下的服務鑒權能力，如何建設一套符合螞蟻架構的 Workload 間的服務鑒權能力，我們将問題分為一下三個子問題：
1、Workload 的身份如何定義，如何能夠實作一套通用的身份辨別的體系；
2、Workload 間通路的授權模型的實作；
3、通路控制執行點如何選擇。
Workload 身份定義 & 認證方式
螞蟻内部使用 SPIFFE 項目中給出的 Identity 格式來描述 Workload 的身份，即：
spiffe://<domain>/cluster/<cluster>/ns/<namespace> 不過在工程落地過程中發現，這種次元的身份格式粒度不夠細，并且與 K8s 對于 namespace 的劃分規則有較強的耦合。螞蟻的體量較大，場景較多，不同場景下 namespace 的劃分規則都不完全一緻。是以我們對格式進行了調整，在每一場景下梳理出能夠辨別一個 Workload 示例所須要的一組必備屬性（例如應用名，環境資訊等），并将這些屬性攜帶在 Pod 的 Labels 中。調整後的格式如下：
spiffe://<domain>/cluster/<cluster>/<required_attr_1_name>/<required_attr_1_value>/<required_attr_2_name>/<required_attr_2_value> 配合這個身份格式标準，我們在 K8s API Server 中添加了 Validating Webhook 元件，對上述 Labels 中必須攜帶的屬性資訊進行校驗。如果缺少其中一項屬性資訊，則執行個體 Pod 将無法建立。如下圖所示：
在解決了 Workload 身份定義的問題後，剩下的就是如何将身份轉換成某種可校驗的格式，在 Workload 之間的服務調用鍊路中透傳。為了支援不同的使用場景，我們選擇了 X.509 證書與 JWT 這兩種格式。
對于 Service Mesh 架構的場景，我們将身份資訊存放在 X.509 證書的 Subject 字段中，以此來攜帶 Workload 的身份資訊。如下圖所示：
對于其他場景，我們将身份資訊存放在 JWT 的 Claims 中，而 JWT 的頒發與校驗，采用了 Secure Sidecar 提供服務。如下圖所示：
授權模型
在項目落地的初期，使用 RBAC 模型來描述 Workload 間服務調用的授權政策。舉例描述，應用 A 的某一個服務，隻能被應用 B 調用。這種授權政策在大多數場景下都沒有問題，不過在項目推進過程中，我們發現這種授權政策不适用于部分特殊場景。
我們考慮這樣一個場景，生産網内部有一個應用 A，職責是對生産網内部的所有應用在運作時所需要使用的一些動态配置提供中心化的服務。這個服務的定義如下：
A 應用 - 擷取動态配置的 RPC 服務：
message FetchResourceRequest {<br />// The appname of invoker<br />string appname = 1;<br />// The ID of resource<br />string resource_id = 2;<br />}<br />message FetchResourceResponse {<br />string data = 1;<br />}<br />service DynamicResourceService {<br />rpc FetchResource (FetchResourceRequest) returns (FetchResourceResponse) {}<br />}<br />
在此場景下，如果依然使用 RBAC 模型，應用 A 的通路控制政策将無法描述，因為所有應用都需要通路 A 應用的服務。但是這樣會導緻顯而易見的安全問題，調用方應用 B 可以通過該服務擷取到其它應用的資源。是以我們将 RBAC 模型更新為 ABAC 模型來解決上述問題。 我們采用 DSL 語言來描述 ABAC 的邏輯，并且內建在 Secure Sidecar 中。
通路控制執行點的選擇
在執行點選擇方面，考慮到 Service Mesh 架構推進需要一定的時間，我們提供了兩不同的方式，可以相容 Service Mesh 的架構，也可以相容目前場景。
在 Service Mesh 架構場景下，RBAC Filter 和 ABAC Filter（Access Control Filter）內建在 Mesh Sidecar 中。
在目前場景下，我們目前提供了 JAVA SDK，應用需要內建 SDK 來完成所有認證和授權相關的邏輯。與 Service Mesh 架構場景類似，所有 Identity 的頒發、校驗，授權與 Secure Sidecar 互動，由 Secure Sidecar 完成。
結語
零信任的核心是“Never Trust， Always Verify”，未來會繼續深化零信任在整個阿裡巴巴的實踐，賦予不同的角色不同的身份，例如企業員工、應用、機器，并将通路控制點下沉到雲原生基礎設施的各個點，實作全局細粒度的控制，打造安全防護的新邊界。本文從業界的零信任體系的落地最佳實踐，到基于 Kubernetes 的零信任落地方式進行了簡單的描述，本文隻是抛磚引玉，希望能引發更多關于 Cloud Native 下的零信任架構體系的更多讨論和能看到更多的業界優秀的方案和産品能出現。
“阿裡巴巴雲原生微信公衆号（ID：Alicloudnative）關注微服務、Serverless、容器、Service Mesh 等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，做最懂雲原生開發者的技術公衆号。”