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

簡(jiǎn)介

零信任安全最早由著名研究機(jī)構(gòu) Forrester 的首席分析師約翰.金德維格在 2010 年提出。零信任安全針對(duì)傳統(tǒng)邊界安全架構(gòu)思想進(jìn)行了重新評(píng)估和審視，并對(duì)安全架構(gòu)思路給出了新的建議。

其核心思想是，默認(rèn)情況下不應(yīng)該信任網(wǎng)絡(luò)內(nèi)部和外部的任何人/設(shè)備/系統(tǒng)，需要基于認(rèn)證和授權(quán)重構(gòu)訪問控制的信任基礎(chǔ)。諸如 IP 地址、主機(jī)、地理位置、所處網(wǎng)絡(luò)等均不能作為可信的憑證。零信任對(duì)訪問控制進(jìn)行了范式上的顛覆，引導(dǎo)安全體系架構(gòu)從“網(wǎng)絡(luò)中心化”走向“身份中心化”，其本質(zhì)訴求是以身份為中心進(jìn)行訪問控制。

目前落地零信任概念包括 Google BeyondCorp、Google ALTS、Azure Zero Trust Framework 等，云上零信任體系，目前還是一個(gè)新興的技術(shù)趨勢(shì)方向，同樣的零信任模型也同樣適用于 Kubernetes，本文重點(diǎn)講解一下 Kubernetes 下零信任安全架構(gòu)的技術(shù)分析。

傳統(tǒng)零信任概念和目前落地情況

Microsoft Azure

Azure 的零信任相對(duì)來說還是比較完善的，從體系角度來看涵蓋了端、云、On-Permises、SaaS 等應(yīng)用，下面我們分析一下相關(guān)的組件：

• 用戶 Identity：然后通過 Identity Provider（創(chuàng)建、維護(hù)和管理用戶身份的組件）的認(rèn)證，再認(rèn)證的過程中可以使用賬號(hào)密碼，也可以使用 MFA（Multi Factor Auth）多因素認(rèn)證的方式，多因素認(rèn)證包括軟、硬 Token、SMS、人體特征等；
• 設(shè)備 Identity：設(shè)備包含了公司的設(shè)備以及沒有統(tǒng)一管理的設(shè)備，這些設(shè)備的信息，包含 IP 地址、MAC 地址、安裝的軟件、操作系統(tǒng)版本、補(bǔ)丁狀態(tài)等存儲(chǔ)到 Device Inventory；另外設(shè)備也會(huì)有相應(yīng)的 Identity 來證明設(shè)備的身份；設(shè)備會(huì)有對(duì)應(yīng)的設(shè)備狀態(tài)、設(shè)備的風(fēng)險(xiǎn)進(jìn)行判定；
• Security Policy Enforcement：通過收集的用戶 Identity 以及狀態(tài)、設(shè)備的信息，狀態(tài)以及 Identity 后，SPE 策略進(jìn)行綜合的判定，同時(shí)可以結(jié)合 Threat Intelligence 來增強(qiáng) SPE 的策略判定的范圍和準(zhǔn)備性；策略的例子包括可以訪問后面的 Data、Apps、Infrastructure、Network；
• Data：針對(duì)數(shù)據(jù)（Emails、Documents）進(jìn)行分類、標(biāo)簽、加密的策略；
• Apps：可以自適應(yīng)訪問對(duì)應(yīng)的 SaaS 應(yīng)用和 On-Permises 應(yīng)用；
• Infrastructure：包括 IaaS、PaaS、Container、Serverless 以及 JIT（按需開啟訪問）和 GIT 版本控制軟件；
• Network：針對(duì)網(wǎng)絡(luò)交付過程以及內(nèi)部的微隔離進(jìn)行策略打通。

下面這張微軟的圖進(jìn)行了更加細(xì)化的講解，用戶（員工、合作伙伴、用戶等）包括 Azure AD、ADFS、MSA、Google ID 等，設(shè)備（可信的合規(guī)設(shè)備）包括 Android、iOS、MacOS、Windows、Windows Defender ATP，客戶端（客戶端 APP 以及認(rèn)證方式）包括瀏覽器以及客戶端應(yīng)用，位置（物理和虛擬地址）包括地址位置信息、公司網(wǎng)絡(luò)等，利用 Microsoft 的機(jī)器學(xué)習(xí) ML、實(shí)時(shí)評(píng)估引擎、策略等進(jìn)行針對(duì)用戶、客戶端、位置和設(shè)備進(jìn)行綜合判定，來持續(xù)自適應(yīng)的訪問 On-Permises、Cloud SaaS Apps、Microsoft Cloud，包含的策略包括 Allow、Deny，限制訪問、開啟 MFA、強(qiáng)制密碼重置、阻止和鎖定非法認(rèn)證等；從下圖可以看出 Azure 已經(jīng)打通了 On-Permises、Cloud、SaaS 等各個(gè)層面，構(gòu)建了一個(gè)大而全的零信任體系。

Google BeyondCorp

Google BeyondCorp 是為了應(yīng)對(duì)新型網(wǎng)絡(luò)威脅的一種網(wǎng)絡(luò)安全解決方案，其實(shí) Google BeyondCorp 本身并沒有太多的技術(shù)上的更新?lián)Q代，而是利用了持續(xù)驗(yàn)證的一種思路來做的，去掉了 VPN 和不再分內(nèi)外網(wǎng)。Google 在 2014 年之前就預(yù)測(cè)到互聯(lián)網(wǎng)和內(nèi)網(wǎng)的安全性是一樣危險(xiǎn)的，因?yàn)橐坏﹥?nèi)網(wǎng)邊界被突破的話，攻擊者就很容易的訪問企業(yè)的一些內(nèi)部應(yīng)用，由于安全意識(shí)的問題導(dǎo)致企業(yè)會(huì)認(rèn)為我的內(nèi)部很安全，我就對(duì)內(nèi)部的應(yīng)用進(jìn)行低優(yōu)先級(jí)別的處理，導(dǎo)致大量?jī)?nèi)部的安全問題存在。現(xiàn)在的企業(yè)越來越多的應(yīng)用移動(dòng)和云技術(shù)，導(dǎo)致邊界保護(hù)越來越難。所以 Google 干脆一視同仁，不分內(nèi)外部，用一樣的安全手段去防御。

從攻防角度來看一下 Google 的 BeyondCorp 模型，例如訪問 Google 內(nèi)部應(yīng)用http://blackberry.corp.google.com ，它會(huì)跳轉(zhuǎn)到https://login.corp.google.com/ 也就是 Google Moma 系統(tǒng)，首先需要輸入賬號(hào)密碼才能登陸，這個(gè)登錄的過程中會(huì)針對(duì)設(shè)備信息、用戶信息進(jìn)行綜合判定，賬號(hào)密碼正確以及設(shè)備信息通過規(guī)則引擎驗(yàn)證之后，會(huì)繼續(xù)跳轉(zhuǎn)到需要 YubiKey 登錄界面，每個(gè) Google 的員工都會(huì)有 Yubikey，通過 Yubikey 來做二次驗(yàn)證。Yubikey 的價(jià)值，Google 認(rèn)為是可以完全杜絕釣魚攻擊的。另外類似的就是 Amazon 的 Midway-Auth 方式 （ https://midway-auth.amazon.com/login?next=/ ）。

Kubernetes 下容器零信任模型

容器下網(wǎng)絡(luò)零信任

首先介紹一下容器下的網(wǎng)絡(luò)零信任組件 Calico，Calico 是針對(duì)容器，虛擬機(jī)和基于主機(jī)的本機(jī) Workload 的開源網(wǎng)絡(luò)和網(wǎng)絡(luò)安全解決方案產(chǎn)品。Calico 支持廣泛的平臺(tái)，包括 Kubernetes、OpenShift、Docker EE、OpenStack 和裸金屬服務(wù)。零信任最大的價(jià)值就是即使攻擊者通過其他各種手法破壞應(yīng)用程序或基礎(chǔ)架構(gòu)，零信任網(wǎng)絡(luò)也具有彈性。零信任架構(gòu)使得使攻擊者難以橫向移動(dòng)，針對(duì)性的踩點(diǎn)活動(dòng)也更容易發(fā)現(xiàn)。

在容器網(wǎng)絡(luò)零信任體系下，Calico Istio 目前是比較熱的一套解決方案；先來看看兩者的一些差別，從差別上可以看到 Istio 是針對(duì) Pod 層 Workload 的訪問控制，以及 Calico 針對(duì) Node 層的訪問控制：

IstioCalico

Layer	L3-L7	L3-L4
實(shí)現(xiàn)方式	用戶態(tài)	內(nèi)核態(tài)
策略執(zhí)行點(diǎn)	Pod	Node

下面重點(diǎn)講解一下 Calico 組件和 Istio 的一些技術(shù)細(xì)節(jié)，Calico 構(gòu)建了一個(gè) 3 層可路由網(wǎng)絡(luò)，通過 Calico 的 Felix（是運(yùn)行在 Node 的守護(hù)程序，它在每個(gè) Node 資源上運(yùn)行。Felix 負(fù)責(zé)編制路由和 ACL 規(guī)則以及在該 Node 主機(jī)上所需的任何其他內(nèi)容，以便為該主機(jī)上的資源正常運(yùn)行提供所需的網(wǎng)絡(luò)連接）運(yùn)行在每個(gè) Node 上，主要做路由和 ACL 的策略以及搭建網(wǎng)絡(luò)；通過運(yùn)行在 Node 上的 Iptables 進(jìn)行細(xì)粒度的訪問控制。可以通過 Calico 設(shè)置默認(rèn) Deny 的策略，然后通過自適應(yīng)的訪問控制來進(jìn)行最小化的訪問控制策略的執(zhí)行，從而構(gòu)建容器下的零信任體系；Dikastes/Envoy：可選的 Kubernetes sidecars，可以通過相互 TLS 身份驗(yàn)證保護(hù) Workload 到 Workload 的通信，并增加相關(guān)的控制策略；

Istio

再講解 Istio 之前先講一下微服務(wù)的一些安全需求和風(fēng)險(xiǎn)分析：

1、微服務(wù)被突破之后通過 Sniffer 監(jiān)控流量，進(jìn)而進(jìn)行中間人攻擊，為了解決這種風(fēng)險(xiǎn)需要對(duì)流量進(jìn)行加密；
2、為了針對(duì)微服務(wù)和微服務(wù)之間的訪問控制，需要雙向 TLS 和細(xì)粒度的訪問策略；
3、要審核誰在什么時(shí)候做了什么，需要審計(jì)工具；

分析了對(duì)應(yīng)的風(fēng)險(xiǎn)之后，下面來解釋一下 Istio 如何實(shí)現(xiàn)的零信任架構(gòu)。首先很明顯的一個(gè)特點(diǎn)就是全鏈路都是雙向 mTLS 進(jìn)行加密的，第二個(gè)特點(diǎn)就是微服務(wù)和微服務(wù)之間的訪問也可以進(jìn)行鑒權(quán)，通過權(quán)限訪問之后還需要進(jìn)行審計(jì)。Istio 是數(shù)據(jù)面和控制面進(jìn)行分離的，控制面是通過 Pilot 將授權(quán)策略和安全命名信息分發(fā)給 Envoy，然后數(shù)據(jù)面通過 Envoy 來進(jìn)行微服務(wù)的通信。在每個(gè)微服務(wù)的 Workload 上都會(huì)部署 Envoy，每個(gè) Envoy 代理都運(yùn)行一個(gè)授權(quán)引擎，該引擎在運(yùn)行時(shí)授權(quán)請(qǐng)求。當(dāng)請(qǐng)求到達(dá)代理時(shí)，授權(quán)引擎根據(jù)當(dāng)前授權(quán)策略評(píng)估請(qǐng)求上下文，并返回授權(quán)結(jié)果 ALLOW 或 DENY。

微服務(wù)下的 Zero Trust API 安全

42Crunch（ https://42crunch.com/ ）將 API 安全從企業(yè)邊緣擴(kuò)展到了每個(gè)單獨(dú)的微服務(wù)，并通過可大規(guī)模部署的超低延遲微 API 防火墻來進(jìn)行保護(hù)。 42Crunch API 防火墻的部署模式是以 Kubernetes Pod 中以 Sidecar 代理模式部署，毫秒級(jí)別的性能響應(yīng)。 這省去了編寫和維護(hù)單個(gè) API 安全策略過程，并實(shí)施了零信任安全體系結(jié)構(gòu)，提升了微服務(wù)下的 API 安全性。42Crunch 的 API 安全能力包括：審核：運(yùn)行 200 多個(gè) OpenAPI 規(guī)范定義的安全審核測(cè)試，并進(jìn)行詳細(xì)的安全評(píng)分，以幫助開發(fā)人員定義和加強(qiáng) API 安全；掃描：掃描實(shí)時(shí) API 端點(diǎn)，以發(fā)現(xiàn)潛在的漏洞；保護(hù)：保護(hù) API 并在應(yīng)用上部署輕量級(jí)，低延遲 Micro API Firewall。

螞蟻零信任架構(gòu)體系落地最佳實(shí)踐

隨著 Service Mesh 架構(gòu)的演進(jìn)，螞蟻已經(jīng)開始在內(nèi)部落地 Workload 場(chǎng)景下的服務(wù)鑒權(quán)能力，如何建設(shè)一套符合螞蟻架構(gòu)的 Workload 間的服務(wù)鑒權(quán)能力，我們將問題分為一下三個(gè)子問題：

1、Workload 的身份如何定義，如何能夠?qū)崿F(xiàn)一套通用的身份標(biāo)識(shí)的體系；
2、Workload 間訪問的授權(quán)模型的實(shí)現(xiàn)；
3、訪問控制執(zhí)行點(diǎn)如何選擇。

Workload 身份定義 & 認(rèn)證方式

螞蟻內(nèi)部使用 SPIFFE 項(xiàng)目中給出的 Identity 格式來描述 Workload 的身份，即：

spiffe://<domain>/cluster/<cluster>/ns/<namespace>

不過在工程落地過程中發(fā)現(xiàn)，這種維度的身份格式粒度不夠細(xì)，并且與 K8s 對(duì)于 namespace 的劃分規(guī)則有較強(qiáng)的耦合。螞蟻的體量較大，場(chǎng)景較多，不同場(chǎng)景下 namespace 的劃分規(guī)則都不完全一致。因此我們對(duì)格式進(jìn)行了調(diào)整，在每一場(chǎng)景下梳理出能夠標(biāo)識(shí)一個(gè) Workload 示例所須要的一組必備屬性（例如應(yīng)用名，環(huán)境信息等），并將這些屬性攜帶在 Pod 的 Labels 中。調(diào)整后的格式如下：

spiffe://<domain>/cluster/<cluster>/<required_attr_1_name>/<required_attr_1_value>/<required_attr_2_name>/<required_attr_2_value>

配合這個(gè)身份格式標(biāo)準(zhǔn)，我們?cè)?K8s API Server 中添加了 Validating Webhook 組件，對(duì)上述 Labels 中必須攜帶的屬性信息進(jìn)行校驗(yàn)。如果缺少其中一項(xiàng)屬性信息，則實(shí)例 Pod 將無法創(chuàng)建。如下圖所示：

在解決了 Workload 身份定義的問題后，剩下的就是如何將身份轉(zhuǎn)換成某種可校驗(yàn)的格式，在 Workload 之間的服務(wù)調(diào)用鏈路中透?jìng)鳌榱酥С植煌氖褂脠?chǎng)景，我們選擇了 X.509 證書與 JWT 這兩種格式。

對(duì)于 Service Mesh 架構(gòu)的場(chǎng)景，我們將身份信息存放在 X.509 證書的 Subject 字段中，以此來攜帶 Workload 的身份信息。如下圖所示：

對(duì)于其他場(chǎng)景，我們將身份信息存放在 JWT 的 Claims 中，而 JWT 的頒發(fā)與校驗(yàn)，采用了 Secure Sidecar 提供服務(wù)。如下圖所示：

授權(quán)模型

在項(xiàng)目落地的初期，使用 RBAC 模型來描述 Workload 間服務(wù)調(diào)用的授權(quán)策略。舉例描述，應(yīng)用 A 的某一個(gè)服務(wù)，只能被應(yīng)用 B 調(diào)用。這種授權(quán)策略在大多數(shù)場(chǎng)景下都沒有問題，不過在項(xiàng)目推進(jìn)過程中，我們發(fā)現(xiàn)這種授權(quán)策略不適用于部分特殊場(chǎng)景。

我們考慮這樣一個(gè)場(chǎng)景，生產(chǎn)網(wǎng)內(nèi)部有一個(gè)應(yīng)用 A，職責(zé)是對(duì)生產(chǎn)網(wǎng)內(nèi)部的所有應(yīng)用在運(yùn)行時(shí)所需要使用的一些動(dòng)態(tài)配置提供中心化的服務(wù)。這個(gè)服務(wù)的定義如下：A 應(yīng)用 - 獲取動(dòng)態(tài)配置的 RPC 服務(wù)：

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) {} }

在此場(chǎng)景下，如果依然使用 RBAC 模型，應(yīng)用 A 的訪問控制策略將無法描述，因?yàn)樗袘?yīng)用都需要訪問 A 應(yīng)用的服務(wù)。但是這樣會(huì)導(dǎo)致顯而易見的安全問題，調(diào)用方應(yīng)用 B 可以通過該服務(wù)獲取到其它應(yīng)用的資源。因此我們將 RBAC 模型升級(jí)為 ABAC 模型來解決上述問題。 我們采用 DSL 語言來描述 ABAC 的邏輯，并且集成在 Secure Sidecar 中。

訪問控制執(zhí)行點(diǎn)的選擇

在執(zhí)行點(diǎn)選擇方面，考慮到 Service Mesh 架構(gòu)推進(jìn)需要一定的時(shí)間，我們提供了兩不同的方式，可以兼容 Service Mesh 的架構(gòu)，也可以兼容當(dāng)前場(chǎng)景。

在 Service Mesh 架構(gòu)場(chǎng)景下，RBAC Filter 和 ABAC Filter（Access Control Filter）集成在 Mesh Sidecar 中。

在當(dāng)前場(chǎng)景下，我們目前提供了 JAVA SDK，應(yīng)用需要集成 SDK 來完成所有認(rèn)證和授權(quán)相關(guān)的邏輯。與 Service Mesh 架構(gòu)場(chǎng)景類似，所有 Identity 的頒發(fā)、校驗(yàn)，授權(quán)與 Secure Sidecar 交互，由 Secure Sidecar 完成。

結(jié)語

零信任的核心是“Never Trust， Always Verify”，未來會(huì)繼續(xù)深化零信任在整個(gè)阿里巴巴的實(shí)踐，賦予不同的角色不同的身份，例如企業(yè)員工、應(yīng)用、機(jī)器，并將訪問控制點(diǎn)下沉到云原生基礎(chǔ)設(shè)施的各個(gè)點(diǎn)，實(shí)現(xiàn)全局細(xì)粒度的控制，打造安全防護(hù)的新邊界。本文從業(yè)界的零信任體系的落地最佳實(shí)踐，到基于 Kubernetes 的零信任落地方式進(jìn)行了簡(jiǎn)單的描述，本文只是拋磚引玉，希望能引發(fā)更多關(guān)于 Cloud Native 下的零信任架構(gòu)體系的更多討論和能看到更多的業(yè)界優(yōu)秀的方案和產(chǎn)品能出現(xiàn)。

本書亮點(diǎn)

• 雙11 超大規(guī)模 K8s 集群實(shí)踐中，遇到的問題及解決方法詳述
• 云原生化最佳組合：Kubernetes 容器 神龍，實(shí)現(xiàn)核心系統(tǒng) 100% 上云的技術(shù)細(xì)節(jié)
• 雙 11 Service Mesh 超大規(guī)模落地解決方案

“阿里巴巴云原生關(guān)注微服務(wù)、Serverless、容器、Service Mesh 等技術(shù)領(lǐng)域、聚焦云原生流行技術(shù)趨勢(shì)、云原生大規(guī)模的落地實(shí)踐，做最懂云原生開發(fā)者的技術(shù)圈。”

總結(jié)

以上是生活随笔為你收集整理的Kubernetes 下零信任安全架构分析的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。