近日國內(nèi)外多家安全機構(gòu)監(jiān)測到 Apache Log4j 存在任意代碼執(zhí)行漏洞（漏洞編號：CVE-2021-44228），未取得身份認(rèn)證的用戶，可以從遠(yuǎn)程發(fā)送數(shù)據(jù)請求輸入數(shù)據(jù)日志，輕松觸發(fā)漏洞，最終在目標(biāo)上執(zhí)行任意代碼。

眾所周知，Log4j 在多個微服務(wù)應(yīng)用框架中被廣泛使用，這些分布眾多的微服務(wù)也會增加安全的挑戰(zhàn)，每個微服務(wù)都是一個被攻擊的目標(biāo)。Kubernetes 為托管和編排用戶的微服務(wù)提供了一個出色的平臺。但是，默認(rèn)情況下，微服務(wù)之間的所有交互都不安全。它們通過純文本 HTTP 進(jìn)行通信，但這不足以滿足安全要求。只依賴網(wǎng)絡(luò)邊界來保證安全是不夠的，因為一旦內(nèi)部的某個服務(wù)被攻陷，邊界安全手段就如馬奇諾防線，攻擊者能夠以該機器為跳板來攻擊內(nèi)網(wǎng)。所以，內(nèi)部的調(diào)用也必須安全，這就是零信任的用武之地。

零信任是 Forrester 分析師 John Kindervag 提出的, 是指無論在網(wǎng)絡(luò)邊界內(nèi)部還是外部，都沒有任何隱含的信任可言。換句話說，任何地方都需要顯式認(rèn)證, 并使用最小權(quán)限原則來限制對資源的訪問。
服務(wù)網(wǎng)格技術(shù)的一個重要的價值主張就是它如何有效地保護(hù)應(yīng)用的生產(chǎn)環(huán)境，同時又不降低開發(fā)人員的生產(chǎn)力。通過服務(wù)網(wǎng)格技術(shù)，為微服務(wù)架構(gòu)采用零信任網(wǎng)絡(luò)安全方法提供必要的基礎(chǔ)，以此實現(xiàn)所有訪問都經(jīng)過強身份驗證、基于上下文授權(quán)、記錄監(jiān)控等安全目標(biāo)。使用這些網(wǎng)格功能，您可以為屬于網(wǎng)格的所有應(yīng)用程序提供安全控制能力，例如所有流量都已加密、到應(yīng)用程序的所有流量都通過策略執(zhí)行點（PEP）的驗證等。

由美國國家安全局（NSA）于 2021 年 8 月發(fā)布的《Kubernetes Hardening Guidance》（具體請見文末相關(guān)鏈接 1）也提到了管理員應(yīng)該考慮使用服務(wù)網(wǎng)格來加強 Kubernetes 集群的安全性。

阿里云服務(wù)網(wǎng)格 ASM（具體請見文末相關(guān)鏈接 2）成為重要的云原生零信任體系落地載體之一，將身份驗證和授權(quán)從應(yīng)用程序代碼卸載到服務(wù)網(wǎng)格，開箱即用、動態(tài)可配、更新策略更加容易且立即生效。在使用 Kubernetes Network Policy 實現(xiàn)三層網(wǎng)絡(luò)安全控制之上，服務(wù)網(wǎng)格 ASM 提供了包括對等身份和請求身份認(rèn)證能力、Istio 授權(quán)策略以及更為精細(xì)化管理的基于 OPA(Open Policy Agent) 的策略控制能力。阿里云服務(wù)網(wǎng)格 ASM 提供的這些零信任安全能力, 幫助用戶實現(xiàn)上述這些安全目標(biāo)。

構(gòu)建基于服務(wù)網(wǎng)格的零信任安全能力體系包括了以下幾個方面：

1. 零信任的基礎(chǔ) - 工作負(fù)載身份；如何為云原生工作負(fù)載提供統(tǒng)一的身份；ASM 產(chǎn)品為服務(wù)網(wǎng)格下的每一個工作負(fù)載提供了簡單易用的身份定義，并根據(jù)特定場景提供定制機制用于擴(kuò)展身份構(gòu)建體系, 同時兼容社區(qū) SPIFFE 標(biāo)準(zhǔn)；

   
   

2. 零信任的載體 - 安全證書，ASM 產(chǎn)品提供了如何簽發(fā)證書以及管理證書的生命周期、輪轉(zhuǎn)等機制，通過 X509 TLS 證書建立身份，每個代理都使用該證書。并提供證書和私鑰輪換；

   
   

3. 零信任的引擎 - 策略執(zhí)行，基于策略的信任引擎是構(gòu)建零信任的關(guān)鍵核心，ASM 產(chǎn)品除了支持 Istio RBAC 授權(quán)策略之外，還提供了基于 OPA 提供更加細(xì)粒度的授權(quán)策略；

   
   

4. 零信任的洞察 - 可視化與分析，ASM 產(chǎn)品提供了可觀測機制用于監(jiān)視策略執(zhí)行的日志和指標(biāo)，來判斷每一個策略的執(zhí)行情況等；

01

為什么要使用服務(wù)網(wǎng)格

實現(xiàn)零信任？

Cloud Native

與直接在應(yīng)用程序代碼中構(gòu)建這些安全機制的傳統(tǒng)方法相比,服務(wù)網(wǎng)格體系結(jié)構(gòu)具有以下多種安全性好處：

• Sidecar 代理的生命周期與應(yīng)用程序保持獨立，因此可以更輕松地管理這些 Sidecar 代理。

• 允許動態(tài)配置，更新策略變得更加容易，更新立即生效，而無需重新部署應(yīng)用程序。

• 服務(wù)網(wǎng)格的集中控制架構(gòu)使企業(yè)的安全團(tuán)隊可以構(gòu)建、管理和部署適用于整個企業(yè)的安全策略，從而默認(rèn)情況下就能確保應(yīng)用開發(fā)人員構(gòu)建的業(yè)務(wù)應(yīng)用的安全。他們無需額外的工作即可立即使用這些安全策略。

• 服務(wù)網(wǎng)格提供了對附加到請求的終端用戶憑據(jù)進(jìn)行身份驗證的能力如 JWT。

• 此外, 使用服務(wù)網(wǎng)格體系結(jié)構(gòu)，可以將身份驗證和授權(quán)系統(tǒng)作為服務(wù)部署在網(wǎng)格中。這樣一來，如同網(wǎng)格中的其他服務(wù)一樣，這些安全系統(tǒng)從網(wǎng)格中本身也可以得到安全保證，包括傳輸中的加密、身份識別、策略執(zhí)行點、終端用戶憑據(jù)的身份驗證和授權(quán)等。

借助阿里云服務(wù)網(wǎng)格 ASM，可以使用單個控制平面來實施強大的身份和訪問管理，透明的 TLS 和加密，身份驗證和授權(quán)以及審核日志記錄。阿里云服務(wù)網(wǎng)格 ASM 開箱即用地提供了這些功能，并且安裝和管理它的簡單性使開發(fā)人員，系統(tǒng)管理員和安全團(tuán)隊可以適當(dāng)?shù)乇Ｗo(hù)其微服務(wù)應(yīng)用程序。

02

阿里云服務(wù)網(wǎng)格 ASM中的

零信任體系

Cloud Native

服務(wù)網(wǎng)格能夠減小云原生環(huán)境中的被攻擊面積，并提供零信任應(yīng)用網(wǎng)絡(luò)所需的基礎(chǔ)框架。通過 ASM 管理服務(wù)到服務(wù)的安全性，可以確保服務(wù)網(wǎng)格的端到端加密、服務(wù)級別身份認(rèn)證和細(xì)粒度授權(quán)策略。

在服務(wù)網(wǎng)格體系下, 可以支持：

• 在服務(wù)之間實施雙向 TLS 認(rèn)證或者面向 server 側(cè)的 TLS 認(rèn)證，支持證書的自動輪轉(zhuǎn)等生命周期管理。網(wǎng)格內(nèi)的通信都經(jīng)過身份驗證和加密處理。

• 啟用基于身份的細(xì)粒度授權(quán)，以及基于其他維度參數(shù)的授權(quán)?；诮巧L問控制 (RBAC) 的基礎(chǔ)，支持 “最低權(quán)限” 的立場，也就是只有經(jīng)過授權(quán)的服務(wù)才能根據(jù) ALLOW/DENY 規(guī)則相互通信。

  
  

  

  
  

當(dāng)前, 阿里云服務(wù)網(wǎng)格 ASM 提供了如下的零信任安全基本能力：
1
工作負(fù)載身份

當(dāng)應(yīng)用程序在服務(wù)網(wǎng)格環(huán)境中運行時，服務(wù)網(wǎng)格會為每個服務(wù)提供一個唯一標(biāo)識。連接到服務(wù)網(wǎng)格中運行的其他微服務(wù)時，將會使用該標(biāo)識。服務(wù)標(biāo)識可用于服務(wù)的雙向驗證，以此進(jìn)行驗證是否允許服務(wù)間的訪問，同時該服務(wù)標(biāo)識也可用于授權(quán)策略中。

當(dāng)使用服務(wù)網(wǎng)格 ASM 管理運行在 Kubernetes 上的工作負(fù)載或者基于 WorkloadEntry 定義虛擬機工作負(fù)載時，ASM 會為每個工作負(fù)載提供服務(wù)身份；該身份基于工作負(fù)載的服務(wù)帳戶令牌實現(xiàn)。

ASM 中的服務(wù)身份符合 SPIFFE 標(biāo)準(zhǔn)，并具有以下格式：spiffe:///ns//sa/

在服務(wù)網(wǎng)格 ASM 控制臺上，打開對應(yīng)的 ASM 實例，在左側(cè)導(dǎo)航欄中可以看到如下零信任安全下的工作負(fù)載身份。

數(shù)據(jù)面中的 Kubernetes 集群下的工作負(fù)載及其身份定義：

基于 WorkloadEntry 定義虛擬機工作負(fù)載及其身份定義：

2 對等身份認(rèn)證

認(rèn)證指的是身份：這個服務(wù)是誰？這個最終用戶是誰？我可以相信他們就是他們所說的那樣嗎？
ASM產(chǎn)品提供了兩種身份驗證：

• 對等身份驗證 - 當(dāng)兩個微服務(wù)相互交互時，啟用還是禁用雙向TLS進(jìn)行對等身份驗證。

• 請求身份驗證 - 允許最終用戶和系統(tǒng)使用請求身份認(rèn)證與微服務(wù)進(jìn)行交互。通常使用JSON Web令牌（JWT）執(zhí)行該操作。

按照入門指引（具體請見文末相關(guān)鏈接 3）安裝部署 bookinfo 示例。

首先，當(dāng)嘗試從同一命名空間（例如本示例中為 default）中的 productpage pod 使用純 HTTP 訪問 details 服務(wù)時，默認(rèn)情況下請求應(yīng)該以 status 200 成功返回。這是因為在默認(rèn)情況下，TLS 和純文本流量都可以被接受。

kubectl exec $(kubectl get pod -l app=productpage -o jsonpath={.items..metadata.name}) -c istio-proxy -- curl http://details:9080/details/1 -o /dev/null -s -w '%{http_code}\n'

接著，在命名空間 default 下定義對等身份認(rèn)證。

在服務(wù)網(wǎng)格 ASM 控制臺上，打開對應(yīng)的 ASM 實例，在左側(cè)導(dǎo)航欄中可以看到如下零信任安全下的對等身份認(rèn)證。在右側(cè)頁面中，點擊 “新建雙向 mTLS 模式” 按鈕，為工作負(fù)載 details 定義 mTLS 模式為 STRICT。

再次，使用 productpage pod 使用純 HTTP 訪問 details 服務(wù)時：

kubectl exec $(kubectl get pod -l app=productpage -o jsonpath={.items..metadata.name}) -c istio-proxy -- curl http://details:9080/details/1 -o /dev/null -s -w '%{http_code}\n'000command terminated with exit code 56

退出碼 56 表示接收網(wǎng)絡(luò)數(shù)據(jù)失敗。這是符合預(yù)期的，工作負(fù)載 details 定義了 mTLS 模式為 STRICT，這樣在每個請求中都需要 TLS 證書認(rèn)證。

為了允許正常訪問，可以通過上述定義的對等身份認(rèn)證從 STRICT 修改為 PERMISSIVE。對應(yīng)的 YAML 定義如下：

	
						

							
							

								
							

							

								
							

							

								
							

							

								
							

							

								
							

							

								
							

							

								
							

							

								
							

							

								
							

							

								
							

							

								
							

						

apiVersion: security.istio.io/v1beta1kind: PeerAuthenticationmetadata: name: details-strict namespace: defaultspec: mtls: mode: PERMISSIVE selector: matchLabels: app: details

3 請求身份驗證

首先，我們將創(chuàng)建一個請求身份認(rèn)證策略來對 details 服務(wù)的入站請求強制執(zhí)行 JWT 身份驗證。在服務(wù)網(wǎng)格 ASM 控制臺上，打開對應(yīng)的 ASM 實例，在左側(cè)導(dǎo)航欄中可以看到如下零信任安全下的請求身份認(rèn)證。在右側(cè)頁面中，點擊 “新建” 按鈕，為工作負(fù)載 details 定義 jwt 規(guī)則。

其中，issuer 值設(shè)置為"testing@secure.istio.io"，jwks 的值取自 Istio 安裝文件中的 security/tools/jwt/samples/jwks.json，對應(yīng)如下

{ "keys":[ {"e":"AQAB","kid":"DHFbpoIUqrY8t2zpA2qXfCmr5VO5ZEr4RzHU_-envvQ","kty":"RSA","n":"xAE7eB6qugXyCAG3yhh7pkDkT65pHymX-P7KfIupjf59vsdo91bSP9C8H07pSAGQO1MV_xFj9VswgsCg4R6otmg5PV2He95lZdHtOcU5DXIg_pbhLdKXbi66GlVeK6ABZOUW3WYtnNHD-91gVuoeJT_DwtGGcp4ignkgXfkiEm4sw-4sfb4qdt5oLbyVpmW6x9cfa7vs2WTfURiCrBoUqgBo_-4WTiULmmHSGZHOjzwa8WtrtOQGsAFjIbno85jp6MnGGGZPYZbDAa_b3y5u-YpW7ypZrvD8BgtKVjgtQgZhLAGezMt0ua3DRrWnKqTZ0BJ_EyxOGuHJrLsn00fnMQ"}]}

接著, 嘗試使用 productpage pod 使用純 HTTP 訪問 details 服務(wù)時，可以看到返回結(jié)果為 200。

其中設(shè)置變量 TOKEN 值為：

	
				

					
					

						
					

					

						
					

					

						
					

					

						
					

					

						
					

				

export TOKEN=eyJhbGciOiJSUzI1NiIsImtpZCI6IkRIRmJwb0lVcXJZOHQyenBBMnFYZkNtcjVWTzVaRXI0UnpIVV8tZW52dlEiLCJ0eXAiOiJKV1QifQ.eyJleHAiOjQ2ODU5ODk3MDAsImZvbyI6ImJhciIsImlhdCI6MTUzMjM4OTcwMCwiaXNzIjoidGVzdGluZ0BzZWN1cmUuaXN0aW8uaW8iLCJzdWIiOiJ0ZXN0aW5nQHNlY3VyZS5pc3Rpby5pbyJ9.CfNnxWP2tcnR9q0vxyxweaF3ovQYHYZl82hAUsn21bwQd9zP7c-LS9qd_vpdLG4Tn1A15NxfCjp5f7QNBUo-KC9PJqYpgGbaXhaGx7bEdFWjcwv3nZzvc7M__ZpaCERdwU7igUmJqYGBYQ51vr2njU9ZimyKkfDe3axcyiBZde7G6dabliUosJvvKOPcKIWPccCgefSj_GNfwIip3-SsFdlR7BtbVUcqR-yv-XOxJ3Uc1MI0tz3uMiiZcyPV7sNCU4KRnemRIMHVOfuvHsU60_GhGbiSFzgPTAa9WTltbnarTbxudb_YEOx12JiwYToeX0DCPb43W1tzIBxgm8NxUg kubectl exec $(kubectl get pod -l app=productpage -o jsonpath={.items..metadata.name}) -c istio-proxy -- curl http://details:9080/details/1 -o /dev/null --header "Authorization: Bearer $TOKEN" -s -w '%{http_code}\n' 200

如果傳遞的是無效令牌，我們應(yīng)該看到 “401: Unauthorized” 響應(yīng)：

	
				

					
					

						
					

					

						
					

					

						
					

				

kubectl exec $(kubectl get pod -l app=productpage -o jsonpath={.items..metadata.name}) -c istio-proxy -- curl http://details:9080/details/1 -o /dev/null --header "Authorization: Bearer badtoken" -s -w '%{http_code}\n' 401

但是，如果我們根本不傳遞令牌，RequestAuthentication 則不會調(diào)用該策略。不使用 JWT Token 的請求, 同樣也返回了 200。

	
				

					
					

						
					

					

						
					

					

						
					

				

kubectl exec $(kubectl get pod -l app=productpage -o jsonpath={.items..metadata.name}) -c istio-proxy -- curl http://details:9080/details/1 -o /dev/null  -s -w '%{http_code}\n' 200

因此，除了此身份驗證策略之外，我們還需要一個授權(quán)策略，該策略要求對所有請求進(jìn)行 JWT。下一部分會講述如何在 ASM 產(chǎn)品中定義授權(quán)策略。
4 授權(quán)策略

ASM 產(chǎn)品提供了授權(quán)策略，可以使用授權(quán)策略 AuthorizationPolicy 資源來激活微服務(wù)之間的授權(quán)機制，并使用以下內(nèi)容建立適當(dāng)?shù)牧髁渴跈?quán)策略機制：

• 工作負(fù)載標(biāo)簽選擇 selector 字段指定策略目標(biāo)；

• action 字段指定是 ALLOW 還是 DENY 請求。如果您未指定操作，則操作默認(rèn)設(shè)置為 ALLOW。為清晰起見，我們建議您始終指定操作。（授權(quán)政策還支持 AUDIT 和 CUSTOM 操作）；

• rules 指定何時觸發(fā)操作：

• rules 中的 from 字段指定請求的來源；
• rules 中的 to 字段指定請求的操作；
• when 字段指定為了應(yīng)用規(guī)則所需滿足的其他條件；

對應(yīng)的 YAML 定義如下：

	
						

							
							

								
							

							

								
							

							

								
							

							

								
							

							

								
							

							

								
							

							

								
							

							

								
							

							

								
							

							

								
							

							

								
							

							

								
							

							

								
							

							

								
							

							

								
							

						

apiVersion: security.istio.io/v1beta1kind: AuthorizationPolicymetadata: name: require-jwt namespace: defaultspec: action: ALLOW rules: - from: - source: requestPrincipals: - testing@secure.istio.io/testing@secure.istio.io selector: matchLabels: app: details

再次不使用 JWT Token 發(fā)送請求，您現(xiàn)在應(yīng)該看到 403 - Forbidden。這就是 AuthorizationPolicy 生效了，所有前端請求都必須有一個 JWT Token。

 kubectl exec $(kubectl get pod -l app=productpage -o jsonpath={.items..metadata.name}) -c istio-proxy -- curl http://details:9080/details/1 -o /dev/null  -s -w '%{http_code}\n'403

5 OPA 策略

作為由 CNCF（具體請見文末相關(guān)鏈接 4）托管的一個孵化項目，開放策略代理（OPA）（具體請見文末相關(guān)鏈接 5）是一個策略引擎，可用于為您的應(yīng)用程序?qū)崿F(xiàn)細(xì)粒度的訪問控制。OPA 作為通用策略引擎，可以與微服務(wù)一起部署為獨立服務(wù)。為了保護(hù)應(yīng)用程序，必須先授權(quán)對微服務(wù)的每個請求，然后才能對其進(jìn)行處理。為了檢查授權(quán)，微服務(wù)對 OPA 進(jìn)行 API 調(diào)用，以確定請求是否被授權(quán)。

服務(wù)網(wǎng)格 ASM 集成了開放策略代理（OPA）插件，通過 OPA 定義訪問控制策略，可以使您的應(yīng)用實現(xiàn)細(xì)粒度的訪問控制，并支持動態(tài)更新 OPA 策略。

具體可以參考《在ASM中實現(xiàn)動態(tài)更新OPA策略》（具體請見文末相關(guān)鏈接 6）

6 零信任性能提升

英特爾® 在全新的第三代英特爾® 至強® 可擴(kuò)展處理器（ICELAKE）中引入眾多我們稱為 Crypto Acceleration 加解密加速技術(shù)和架構(gòu)創(chuàng)新，大大提升了一些關(guān)鍵加解密算法的性能。第三代英特爾至強處理器和 Multi-Buffer 技術(shù)所使用的 AVX512 指令集，在阿里云第七代 ECS 服務(wù)器中提供了若干不同的實例類型?；谶@些指令集, 加上融合了 MultiBuffer 技術(shù)的 Envoy 上游社區(qū)能力，阿里云服務(wù)網(wǎng)格 ASM 產(chǎn)品提供了基于 MB 技術(shù)的 TLS 加解密性能優(yōu)化能力。

結(jié)合英特爾的開源軟件庫，例如 IPP 加密庫、IPsec 多緩沖區(qū)加密庫 (intel-ipsec-mb)、英特爾® QuickAssist 技術(shù)（英特爾® QAT）和 OpenSSL 引擎。這些解決方案顯著改善了加密操作，例如 TLS 連接握手性能。這些新組件可以并行處理多個 TLS 私鑰操作。借助 OpenSSL 和 BoringSSL 中都可用的異步私鑰處理機制，應(yīng)用程序軟件可以提交握手私鑰請求，而無需等待一個請求返回，然后才能提交另一個。反過來，一旦準(zhǔn)備好，就會為每個請求調(diào)用一個回調(diào)。在下面，多緩沖區(qū)加密處理可以將 8 個這樣異步提交的私鑰操作，并使用 AVX512 SIMD（單指令多數(shù)據(jù)）指令并行處理，大大提高了整體應(yīng)用性能。

在阿里云 ASM 控制臺中一鍵可以啟用性能優(yōu)化開關(guān)，當(dāng)前這個功能已經(jīng)在產(chǎn)品最新版本中對外開放。
在 KubeCon 2021 大會上阿里云服務(wù)網(wǎng)格 ASM 負(fù)責(zé)人王夕寧和英特爾軟件和先進(jìn)技術(shù)部云計算團(tuán)隊的胡偉將會給大家?guī)硪淮螌ｎ}的技術(shù)分享，屆時我們將會介紹更多的技術(shù)細(xì)節(jié)和實踐的情況。（技術(shù)分享鏈接見文末 7）

03

總結(jié)及參考案例

Cloud Native

綜上所示，服務(wù)網(wǎng)格 ASM 提供了以下用于增強安全性的組件：

• 提供具有完整證書生命周期管理的托管證書基礎(chǔ)設(shè)施，解決了證書頒發(fā)和 CA 輪換的復(fù)雜性；

• 托管的控制面 API，用于向 Envoy 代理分發(fā)身份驗證策略，授權(quán)策略和安全命名信息；

• Sidecar 代理通過提供策略執(zhí)行點 PEP 來幫助確保網(wǎng)格的安全；

• Envoy 代理擴(kuò)展允許遙測數(shù)據(jù)收集和審計；

每一個工作負(fù)載通過 X509 TLS 證書建立身份，每個 Sidecar 代理都使用該證書。服務(wù)網(wǎng)格 ASM 提供并定期輪換證書和私鑰。如果某個特定的私鑰被盜用，服務(wù)網(wǎng)格很快就會用新的私鑰替換它，從而大大減少了攻擊面。
1 參考案例

1. 使用授權(quán)策略在入口網(wǎng)關(guān)上實施基于 IP 的訪問控制（具體請見文末相關(guān)鏈接 8）、或者基于自定義外部授權(quán)的訪問控制等，如下圖所示云產(chǎn)品云原生應(yīng)用交付平臺 ADP（具體請見文末相關(guān)鏈接 9）基于阿里云服務(wù)網(wǎng)格ASM的網(wǎng)關(guān)授權(quán)策略實現(xiàn)。

   

   
   

1. 某互聯(lián)金融客戶在解決跨集群多語言應(yīng)用的訪問權(quán)限控制方面，使用阿里云服務(wù)網(wǎng)格 ASM 提供的授權(quán)策略隔離外聯(lián)區(qū)域和應(yīng)用區(qū)域。同時可以結(jié)合出口網(wǎng)關(guān)來審計出網(wǎng)格的流量，配合上授權(quán)策略，還可以控制應(yīng)用對第三方服務(wù)的訪問權(quán)限。