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

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

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

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

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

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

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

   
   

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

   
   

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

   
   

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

01

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

實(shí)現(xiàn)零信任？

Cloud Native

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

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

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

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

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

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

借助阿里云服務(wù)網(wǎng)格 ASM，可以使用單個(gè)控制平面來(lái)實(shí)施強(qiáng)大的身份和訪問(wèn)管理，透明的 TLS 和加密，身份驗(yàn)證和授權(quán)以及審核日志記錄。阿里云服務(wù)網(wǎng)格 ASM 開(kāi)箱即用地提供了這些功能，并且安裝和管理它的簡(jiǎn)單性使開(kāi)發(fā)人員，系統(tǒng)管理員和安全團(tuán)隊(duì)可以適當(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ǔ)框架。通過(guò) ASM 管理服務(wù)到服務(wù)的安全性，可以確保服務(wù)網(wǎng)格的端到端加密、服務(wù)級(jí)別身份認(rèn)證和細(xì)粒度授權(quán)策略。

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

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

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

  
  

  

  
  

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

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

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

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

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

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

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

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

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

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

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

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

首先，當(dāng)嘗試從同一命名空間（例如本示例中為 default）中的 productpage pod 使用純 HTTP 訪問(wèn) details 服務(wù)時(shí)，默認(rèn)情況下請(qǐng)求應(yīng)該以 status 200 成功返回。這是因?yàn)樵谀J(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 下定義對(duì)等身份認(rèn)證。

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

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

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，這樣在每個(gè)請(qǐng)求中都需要 TLS 證書(shū)認(rèn)證。

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

	
						

							
							

								
							

							

								
							

							

								
							

							

								
							

							

								
							

							

								
							

							

								
							

							

								
							

							

								
							

							

								
							

							

								
							

						

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

3 請(qǐng)求身份驗(yàn)證

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

其中，issuer 值設(shè)置為"testing@secure.istio.io"，jwks 的值取自 Istio 安裝文件中的 security/tools/jwt/samples/jwks.json，對(duì)應(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 訪問(wèn) details 服務(wù)時(shí)，可以看到返回結(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

如果傳遞的是無(wú)效令牌，我們應(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 則不會(huì)調(diào)用該策略。不使用 JWT Token 的請(qǐng)求, 同樣也返回了 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

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

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

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

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

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

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

對(duì)應(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ā)送請(qǐng)求，您現(xiàn)在應(yīng)該看到 403 - Forbidden。這就是 AuthorizationPolicy 生效了，所有前端請(qǐng)求都必須有一個(gè) 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（具體請(qǐng)見(jiàn)文末相關(guān)鏈接 4）托管的一個(gè)孵化項(xiàng)目，開(kāi)放策略代理（OPA）（具體請(qǐng)見(jiàn)文末相關(guān)鏈接 5）是一個(gè)策略引擎，可用于為您的應(yīng)用程序?qū)崿F(xiàn)細(xì)粒度的訪問(wèn)控制。OPA 作為通用策略引擎，可以與微服務(wù)一起部署為獨(dú)立服務(wù)。為了保護(hù)應(yīng)用程序，必須先授權(quán)對(duì)微服務(wù)的每個(gè)請(qǐng)求，然后才能對(duì)其進(jìn)行處理。為了檢查授權(quán)，微服務(wù)對(duì) OPA 進(jìn)行 API 調(diào)用，以確定請(qǐng)求是否被授權(quán)。

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

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

6 零信任性能提升

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

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

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

03

總結(jié)及參考案例

Cloud Native

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

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

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

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

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

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

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

   

   
   

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