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

# 簡介

零信任安全最早由著名研究機構 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：針對網路交付過程以及內部的微隔離進行策略打通。

![1.png](https://ucc.alicdn.com/pic/developer-ecology/2c213cea091c43a59f296d2319926cf1.png)

下面這張微軟的圖進行了更加細化的講解，使用者（員工、合作伙伴、使用者等）包括 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 等各個層面，構建了一個大而全的零信任體系。

![2.png](https://ucc.alicdn.com/pic/developer-ecology/e8b747b0be664eafac6b164bff2a1cc5.png)

## Google BeyondCorp
Google BeyondCorp 是為了應對新型網路威脅的一種網路安全解決方案，其實 Google BeyondCorp 本身並沒有太多的技術上的更新換代，而是利用了持續驗證的一種思路來做的，去掉了 VPN 和不再分內外網。Google 在 2014 年之前就預測到網際網路和內網的安全性是一樣危險的，因為一旦內網邊界被突破的話，攻擊者就很容易的訪問企業的一些內部應用，由於安全意識的問題導致企業會認為~~我的~~內部很安全，~~我~~就對內部的應用進行低優先順序別的處理，導致大量內部的安全問題存在。現在的企業越來越多的應用移動和雲技術，導致邊界保護越來越難。所以 Google 乾脆一視同仁，不分內外部，用一樣的安全手段去防禦。

從攻防角度來看一下 Google 的 BeyondCorp 模型，例如訪問 Google 內部應用[http://blackberry.corp.google.com](http://blackberry.corp.google.com/) ，它會跳轉到[https://login.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) （ [https://midway-auth.amazon.com/login?next=%2F](https://midway-auth.amazon.com/login?next=%2F) ）。
![3.png](https://ucc.alicdn.com/pic/developer-ecology/bc10492cad7447cdb7ebdde59a95f85d.png)

# 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 的通訊，並增加相關的控制策略；

![4.png](https://ucc.alicdn.com/pic/developer-ecology/471cd72246d5406284d577fa2a188b8d.png)

## Istio
再講解 Istio 之前先講一下微服務的一些安全需求和風險分析：

1、微服務被突破之後透過 Sniffer 監控流量，進而進行中間人攻擊，為了解決這種風險需要對流量進行加密；
2、為了針對微服務和微服務之間的訪問控制，需要雙向 TLS 和細粒度的訪問策略；
3、要稽核誰在什麼時候做了什麼，需要審計工具；

分析了對應的風險之後，下面來解釋一下 Istio 如何實現的零信任架構。首先很明顯的一個特點就是全鏈路都是雙向 mTLS 進行加密的，第二個特點就是微服務和微服務之間的訪問也可以進行鑑權，透過許可權訪問之後還需要進行審計。Istio 是資料面和控制面進行分離的，控制面是透過 Pilot 將授權策略和安全命名資訊分發給 Envoy，然後資料面透過 Envoy 來進行微服務的通訊。在每個微服務的 Workload 上都會部署 Envoy，每個 Envoy 代理都執行一個授權引擎，該引擎在執行時授權請求。當請求到達代理時，授權引擎根據當前授權策略評估請求上下文，並返回授權結果 ALLOW 或 DENY。

![5.png](https://ucc.alicdn.com/pic/developer-ecology/eaafe58e03a248faaa15259a16f35e2d.png)

## 微服務下的 Zero Trust API 安全
42Crunch（ [https://42crunch.com/](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 將無法建立。如下圖所示：

![6.png](https://ucc.alicdn.com/pic/developer-ecology/7e3c9129c3f4408c8fcc1a5df170eb36.png)

在解決了 Workload 身份定義的問題後，剩下的就是如何將身份轉換成某種可校驗的格式，在 Workload 之間的服務呼叫鏈路中透傳。為了支援不同的使用場景，我們選擇了 X.509 證照與 JWT 這兩種格式。

對於 Service Mesh 架構的場景，我們將身份資訊存放在 X.509 證照的 Subject 欄位中，以此來攜帶 Workload 的身份資訊。如下圖所示：

![7.png](https://ucc.alicdn.com/pic/developer-ecology/d4865c92ddf84f16bf6eab57328d3631.png)

對於其他場景，我們將身份資訊存放在 JWT 的 Claims 中，而 JWT 的頒發與校驗，採用了 Secure Sidecar 提供服務。如下圖所示：

![8.png](https://ucc.alicdn.com/pic/developer-ecology/452cd11e5b0b4040b81944ac5f01d3f6.png)

#### 授權模型
在專案落地的初期，使用 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 中。

![9.png](https://ucc.alicdn.com/pic/developer-ecology/5f70238a47a24958bdd4c1f7235f64d3.png)

在當前場景下，我們目前提供了 JAVA SDK，應用需要整合 SDK 來完成所有認證和授權相關的邏輯。與 Service Mesh 架構場景類似，所有 Identity 的頒發、校驗，授權與 Secure Sidecar 互動，由 Secure Sidecar 完成。

![10.png](https://ucc.alicdn.com/pic/developer-ecology/19889999e9fa464885a4b93d5164cffb.png)

# 結語
零信任的核心是“Never Trust， Always Verify”，未來會繼續深化零信任在整個阿里巴巴的實踐，賦予不同的角色不同的身份，例如企業員工、應用、機器，並將訪問控制點下沉到雲原生基礎設施的各個點，實現全域性細粒度的控制，打造安全防護的新邊界。本文從業界的零信任體系的落地最佳實踐，到基於 Kubernetes 的零信任落地方式進行了簡單的描述，本文只是拋磚引玉，希望能引發更多關於 Cloud Native 下的零信任架構體系的更多討論和能看到更多的業界優秀的方案和產品能出現。

**本書亮點**

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

> “[阿里巴巴雲原生](https://developer.aliyun.com/group/alisoftwaretech/)關注微服務、Serverless、容器、Service Mesh 等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，做最懂雲原生開發者的技術圈。”</required_attr_2_value></required_attr_2_name></required_attr_1_value></required_attr_1_name></cluster></domain></namespace></cluster></domain>

Kubernetes 下零信任安全架構分析

相關文章