Kubernetes 下零信任安全架構分析

點擊下載《不一樣的 雙11 技術：阿里巴巴經濟體云原生實踐》

本文節選自《不一樣的 雙11 技術：阿里巴巴經濟體云原生實踐》一書，點擊上方圖片即可下載！

作者
楊寧（麟童） 阿里云基礎產品事業部高級安全專家
劉梓溪（寞白） 螞蟻金服大安全基礎安全安全專家
李婷婷（鴻杉） 螞蟻金服大安全基礎安全資深安全專家

簡介

零信任安全最早由著名研究機構 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 本身并沒有太多的技術上的更新換代，而是利用了持續驗證的一種思路來做的，去掉了 *** 和不再分內外網。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 層的訪問控制：

下面重點講解一下 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

再講解 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 調用。這種授權策略在大多數場景下都沒有問題，不過在項目推進過程中，我們發現這種授權策略不適用于部分特殊場景。<br />我們考慮這樣一個場景，生產網內部有一個應用 A，職責是對生產網內部的所有應用在運行時所需要使用的一些動態配置提供中心化的服務。這個服務的定義如下：A 應用 - 獲取動態配置的 RPC 服務：

message FetchResourceRequest {
// The appname of invoker
string appname = 1;
// The ID of resource
string resource_id = 2;
}
message FetchResourceResponse {
string data = 1;
}
service DynamicResourceService {
rpc FetchResource (FetchResourceRequest) returns (FetchResourceResponse) {}
}

在此場景下，如果依然使用 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 下的零信任架構體系的更多討論和能看到更多的業界優秀的方案和產品能出現。

本書亮點

• 雙11 超大規模 K8s 集群實踐中，遇到的問題及解決方法詳述
• 云原生化最佳組合：Kubernetes+容器+神龍，實現核心系統 100% 上云的技術細節
• 雙 11 Service Mesh 超大規模落地解決方案

“阿里巴巴云原生關注微服務、Serverless、容器、Service Mesh 等技術領域、聚焦云原生流行技術趨勢、云原生大規模的落地實踐，做最懂云原生開發者的技術圈。”