如何縮小安全漏洞爆炸半徑，實現服務間零信任安全？

作者：王夕寧, 奇方

近日國內外多家安全機構監測到 Apache Log4j 存在任意程式碼執行漏洞（漏洞編號：CVE-2021-44228），未取得身份認證的使用者，可以從遠端傳送資料請求輸入資料日誌，輕鬆觸發漏洞，最終在目標上執行任意程式碼。

眾所周知，Log4j 在多個微服務應用框架中被廣泛使用，這些分佈眾多的微服務也會增加安全的挑戰，每個微服務都是一個被攻擊的目標。Kubernetes 為託管和編排使用者的微服務提供了一個出色的平臺。但是，預設情況下，微服務之間的所有互動都不安全。它們通過純文字 HTTP 進行通訊，但這不足以滿足安全要求。只依賴網路邊界來保證安全是不夠的，因為一旦內部的某個服務被攻陷，邊界安全手段就如馬奇諾防線，攻擊者能夠以該機器為跳板來攻擊內網。所以，內部的呼叫也必須安全，這就是零信任的用武之地。

零信任是 Forrester 分析師 John Kindervag 提出的, 是指無論在網路邊界內部還是外部，都沒有任何隱含的信任可言。換句話說，任何地方都需要顯式認證, 並使用最小許可權原則來限制對資源的訪問。

服務網格技術的一個重要的價值主張就是它如何有效地保護應用的生產環境，同時又不降低開發人員的生產力。通過服務網格技術，為微服務架構採用零信任網路安全方法提供必要的基礎，以此實現所有訪問都經過強身份驗證、基於上下文授權、記錄監控等安全目標。使用這些網格功能，您可以為屬於網格的所有應用程式提供安全控制能力，例如所有流量都已加密、到應用程式的所有流量都通過策略執行點（PEP）的驗證等。

由美國國家安全域性（NSA）於 2021 年 8 月釋出的《Kubernetes Hardening Guidance》（具體請見文末相關連結 1）也提到了管理員應該考慮使用服務網格來加強 Kubernetes 叢集的安全性。

阿里雲服務網格 ASM（具體請見文末相關連結 2）成為重要的雲原生零信任體系落地載體之一，將身份驗證和授權從應用程式程式碼解除安裝到服務網格，開箱即用、動態可配、更新策略更加容易且立即生效。在使用 Kubernetes Network Policy 實現三層網路安全控制之上，服務網格 ASM 提供了包括對等身份和請求身份認證能力、Istio 授權策略以及更為精細化管理的基於 OPA(Open Policy Agent) 的策略控制能力。阿里雲服務網格 ASM 提供的這些零信任安全能力, 幫助使用者實現上述這些安全目標。

構建基於服務網格的零信任安全能力體系包括了以下幾個方面：

1. 零信任的基礎 - 工作負載身份；如何為雲原生工作負載提供統一的身份；ASM 產品為服務網格下的每一個工作負載提供了簡單易用的身份定義，並根據特定場景提供定製機制用於擴充套件身份構建體系, 同時相容社群 SPIFFE 標準；
2. 零信任的載體 - 安全證照，ASM 產品提供瞭如何簽發證照以及管理證照的生命週期、輪轉等機制，通過 X509 TLS 證照建立身份，每個代理都使用該證照。並提供證照和私鑰輪換；
3. 零信任的引擎 - 策略執行，基於策略的信任引擎是構建零信任的關鍵核心，ASM 產品除了支援 Istio RBAC 授權策略之外，還提供了基於 OPA 提供更加細粒度的授權策略；
4. 零信任的洞察 - 視覺化與分析，ASM 產品提供了可觀測機制用於監視策略執行的日誌和指標，來判斷每一個策略的執行情況等；

為什麼要使用服務網格實現零信任？

與直接在應用程式程式碼中構建這些安全機制的傳統方法相比,服務網格體系結構具有以下多種安全性好處：

• Sidecar 代理的生命週期與應用程式保持獨立，因此可以更輕鬆地管理這些 Sidecar 代理。
• 允許動態配置，更新策略變得更加容易，更新立即生效，而無需重新部署應用程式。
• 服務網格的集中控制架構使企業的安全團隊可以構建、管理和部署適用於整個企業的安全策略，從而預設情況下就能確保應用開發人員構建的業務應用的安全。他們無需額外的工作即可立即使用這些安全策略。
• 服務網格提供了對附加到請求的終端使用者憑據進行身份驗證的能力如 JWT。
• 此外, 使用服務網格體系結構，可以將身份驗證和授權系統作為服務部署在網格中。這樣一來，如同網格中的其他服務一樣，這些安全系統從網格中本身也可以得到安全保證，包括傳輸中的加密、身份識別、策略執行點、終端使用者憑據的身份驗證和授權等。

藉助阿里雲服務網格 ASM，可以使用單個控制平面來實施強大的身份和訪問管理，透明的 TLS 和加密，身份驗證和授權以及稽核日誌記錄。阿里雲服務網格 ASM 開箱即用地提供了這些功能，並且安裝和管理它的簡單性使開發人員，系統管理員和安全團隊可以適當地保護其微服務應用程式。

阿里雲服務網格 ASM中的零信任體系

服務網格能夠減小云原生環境中的被攻擊面積，並提供零信任應用網路所需的基礎框架。通過 ASM 管理服務到服務的安全性，可以確保服務網格的端到端加密、服務級別身份認證和細粒度授權策略。

在服務網格體系下, 可以支援：

• 在服務之間實施雙向 TLS 認證或者面向 server 側的 TLS 認證，支援證照的自動輪轉等生命週期管理。網格內的通訊都經過身份驗證和加密處理。
• 啟用基於身份的細粒度授權，以及基於其他維度引數的授權。基於角色訪問控制 (RBAC) 的基礎，支援 “最低許可權” 的立場，也就是隻有經過授權的服務才能根據 ALLOW/DENY 規則相互通訊。

當前, 阿里雲服務網格 ASM 提供瞭如下的零信任安全基本能力：

工作負載身份

當應用程式在服務網格環境中執行時，服務網格會為每個服務提供一個唯一標識。連線到服務網格中執行的其他微服務時，將會使用該標識。服務標識可用於服務的雙向驗證，以此進行驗證是否允許服務間的訪問，同時該服務標識也可用於授權策略中。

當使用服務網格 ASM 管理執行在 Kubernetes 上的工作負載或者基於 WorkloadEntry 定義虛擬機器工作負載時，ASM 會為每個工作負載提供服務身份；該身份基於工作負載的服務帳戶令牌實現。

ASM 中的服務身份符合 SPIFFE 標準，並具有以下格式：spiffe://<trust-domain>/ns/<namespace>/sa/<service-account>

在服務網格 ASM 控制檯上，開啟對應的 ASM 例項，在左側導航欄中可以看到如下零信任安全下的工作負載身份。

資料面中的 Kubernetes 叢集下的工作負載及其身份定義：

基於 WorkloadEntry 定義虛擬機器工作負載及其身份定義：

對等身份認證

認證指的是身份：這個服務是誰？這個終端使用者是誰？我可以相信他們就是他們所說的那樣嗎？

ASM產品提供了兩種身份驗證：

• 對等身份驗證 - 當兩個微服務相互互動時，啟用還是禁用雙向TLS進行對等身份驗證。
• 請求身份驗證 - 允許終端使用者和系統使用請求身份認證與微服務進行互動。通常使用JSON Web令牌（JWT）執行該操作

按照入門指引（具體請見文末相關連結 3）安裝部署 bookinfo 示例。

首先，當嘗試從同一名稱空間（例如本示例中為 default）中的 productpage pod 使用純 HTTP 訪問 details 服務時，預設情況下請求應該以 status 200 成功返回。這是因為在預設情況下，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 下定義對等身份認證。

在服務網格 ASM 控制檯上，開啟對應的 ASM 例項，在左側導航欄中可以看到如下零信任安全下的對等身份認證。在右側頁面中，點選 “新建雙向 mTLS 模式” 按鈕，為工作負載 details 定義 mTLS 模式為 STRICT。

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

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'
000
command terminated with exit code 56

退出碼 56 表示接收網路資料失敗。這是符合預期的，工作負載 details 定義了 mTLS 模式為 STRICT，這樣在每個請求中都需要 TLS 證照認證。

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

apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: details-strict
  namespace: default
spec:
  mtls:
    mode: PERMISSIVE
  selector:
    matchLabels:
      app: details

\

請求身份驗證

首先，我們將建立一個請求身份認證策略來對 details 服務的入站請求強制執行 JWT 身份驗證。在服務網格 ASM 控制檯上，開啟對應的 ASM 例項，在左側導航欄中可以看到如下零信任安全下的請求身份認證。在右側頁面中，點選 “新建” 按鈕，為工作負載 details 定義 jwt 規則。

其中，issuer 值設定為"testing@secure.istio.io"，jwks 的值取自 Istio 安裝檔案中的 security/tools/jwt/samples/jwks.json，對應如下

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

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

其中設定變數 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

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

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 則不會呼叫該策略。不使用 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

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

授權策略

ASM 產品提供了授權策略，可以使用授權策略 AuthorizationPolicy 資源來啟用微服務之間的授權機制，並使用以下內容建立適當的流量授權策略機制：

• 工作負載標籤選擇 selector 欄位指定策略目標；
• action 欄位指定是 ALLOW 還是 DENY 請求。如果您未指定操作，則操作預設設定為 ALLOW。為清晰起見，我們建議您始終指定操作。（授權政策還支援 AUDIT 和 CUSTOM 操作）；
• rules 指定何時觸發操作：
• • rules 中的 from 欄位指定請求的來源；
  • rules 中的 to 欄位指定請求的操作；
  • when 欄位指定為了應用規則所需滿足的其他條件；

對應的 YAML 定義如下：

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: require-jwt
  namespace: default
spec:
  action: ALLOW
  rules:
    - from:
        - source:
            requestPrincipals:
              - testing@secure.istio.io/testing@secure.istio.io
  selector:
    matchLabels:
      app: details

再次不使用 JWT Token 傳送請求，您現在應該看到 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

OPA 策略

作為由 CNCF（具體請見文末相關連結 4）託管的一個孵化專案，開放策略代理（OPA）（具體請見文末相關連結 5）是一個策略引擎，可用於為您的應用程式實現細粒度的訪問控制。OPA 作為通用策略引擎，可以與微服務一起部署為獨立服務。為了保護應用程式，必須先授權對微服務的每個請求，然後才能對其進行處理。為了檢查授權，微服務對 OPA 進行 API 呼叫，以確定請求是否被授權。

服務網格 ASM 整合了開放策略代理（OPA）外掛，通過 OPA 定義訪問控制策略，可以使您的應用實現細粒度的訪問控制，並支援動態更新 OPA 策略。

具體可以參考《在ASM中實現動態更新OPA策略》（具體請見文末相關連結 6）

零信任效能提升

英特爾® 在全新的第三代英特爾® 至強® 可擴充套件處理器（ICELAKE）中引入眾多我們稱為 Crypto Acceleration 加解密加速技術和架構創新，大大提升了一些關鍵加解密演算法的效能。第三代英特爾至強處理器和 Multi-Buffer 技術所使用的 AVX512 指令集，在阿里雲第七代 ECS 伺服器中提供了若干不同的例項型別。基於這些指令集, 加上融合了 MultiBuffer 技術的 Envoy 上游社群能力，阿里雲服務網格 ASM 產品提供了基於 MB 技術的 TLS 加解密效能優化能力。

結合英特爾的開源軟體庫，例如 IPP 加密庫、IPsec 多緩衝區加密庫 (intel-ipsec-mb)、英特爾® QuickAssist 技術（英特爾® QAT）和 OpenSSL 引擎。這些解決方案顯著改善了加密操作，例如 TLS 連線握手效能。這些新元件可以並行處理多個 TLS 私鑰操作。藉助 OpenSSL 和 BoringSSL 中都可用的非同步私鑰處理機制，應用程式軟體可以提交握手私鑰請求，而無需等待一個請求返回，然後才能提交另一個。反過來，一旦準備好，就會為每個請求呼叫一個回撥。在下面，多緩衝區加密處理可以將 8 個這樣非同步提交的私鑰操作，並使用 AVX512 SIMD（單指令多資料）指令並行處理，大大提高了整體應用效能。

在阿里雲 ASM 控制檯中一鍵可以啟用效能優化開關，當前這個功能已經在產品最新版本中對外開放。

在 KubeCon 2021 大會上阿里雲服務網格 ASM 負責人王夕寧和英特爾軟體和先進技術部雲端計算團隊的胡偉將會給大家帶來一次專題的技術分享，屆時我們將會介紹更多的技術細節和實踐的情況。（技術分享連結見文末 7）

總結及參考案例

綜上所示，服務網格 ASM 提供了以下用於增強安全性的元件：

• 提供具有完整證照生命週期管理的託管證照基礎設施，解決了證照頒發和 CA 輪換的複雜性；
• 託管的控制面 API，用於向 Envoy 代理分發身份驗證策略，授權策略和安全命名資訊；
• Sidecar 代理通過提供策略執行點 PEP 來幫助確保網格的安全；
• Envoy 代理擴充套件允許遙測資料收集和審計；

每一個工作負載通過 X509 TLS 證照建立身份，每個 Sidecar 代理都使用該證照。服務網格 ASM 提供並定期輪換證照和私鑰。如果某個特定的私鑰被盜用，服務網格很快就會用新的私鑰替換它，從而大大減少了攻擊面。

參考案例

1. 使用授權策略在入口閘道器上實施基於 IP 的訪問控制（具體請見文末相關連結 8）、或者基於自定義外部授權的訪問控制等，如下圖所示雲產品雲原生應用交付平臺 ADP（具體請見文末相關連結 9）基於阿里雲服務網格ASM的閘道器授權策略實現。

2. 某互聯金融客戶在解決跨叢集多語言應用的訪問許可權控制方面，使用阿里雲服務網格 ASM 提供的授權策略隔離外聯區域和應用區域。同時可以結合出口閘道器來審計出網格的流量，配合上授權策略，還可以控制應用對第三方服務的訪問許可權。

相關連結

1）《Kubernetes Hardening Guidance》：

​​https://media.defense.gov/2021/Aug/03/2002820425/-1/-1/1/CTR_KUBERNETES%20HARDENING%20GUIDANCE.PDF​​

2）阿里雲服務網格ASM：

​​https://www.aliyun.com/product/servicemesh​​

3）入門指引：

​​https://help.aliyun.com/document_detail/149552.html​​

4）CNCF：

​​https://www.cncf.io/ ​​

5）開放策略代理（OPA）：

​​https://www.openpolicyagent.org/ ​​

6）《在ASM中實現動態更新OPA策略》：​​​​

​​https://help.aliyun.com/document_detail/277428.html​​

7）KubeCon 技術分享：

​​https://kccncosschn21.sched.com/event/rxVz/leng-ssxian-zhi-qiang-tang-jie-asmreintel-multi-bufferjiong-zha-zhi-hui-sponsored-session-using-alibaba-cloud-service-mesh-asm-and-intel-multi-buffer-technology-to-achieve-faster-encrypted-communication-between-application-services​​

8）使用授權策略實現訪問控制

​​https://help.aliyun.com/document_detail/214764.html?spm=a2c4g.11186623.6.613.6b213918q0rlZV#title-f15-wyq-fxg​​

9）雲原生應用交付平臺 ADP：

​​https://adp.console.aliyun.com/ ​​