譯者 | 李睿

　　在構建單片應用程序時，安全性主要是基于外圍的。這意味著使用防火墻保護網絡邊界和訪問控制。隨著微服務架構的出現，靜態和基于網絡的邊界不再有效。

　　如今，應用程序是由Kubernetes等容器編排系統部署和管理的，這些系統分布在整個云平臺中。零信任網絡(ZTN)是跨基于云計算的網絡保護數據的一種不同方法。本文將探討Istio如何利用零信任網絡(ZTN)理念幫助保護微服務。

　　一、什么是零信任網絡(ZTN)?

　　零信任網絡(ZTN)是一種不向用戶、設備和服務授予隱式信任的安全范式，并持續驗證其身份和訪問資源的授權。

　　在微服務架構中，如果一個服務(服務器)接收到來自另一個服務(客戶端)的請求，服務器不應該假設客戶端的可信度。服務器應該首先連續地對客戶端進行身份驗證和授權，然后允許安全地進行通信(參見圖A)。

　　圖A：零信任網絡(ZTN)環境，在多云的微服務之間強制執行連續身份驗證和授權

　　二、為什么零信任網絡環境對于微服務來說是不可避免的?

　　在分布式服務網絡中保護網絡和數據的重要性再怎么強調也不為過。以下是面臨的一些挑戰，指出了微服務需要零信任網絡(ZTN)環境的原因：

　　(1)缺乏網絡所有權：應用程序從基于外圍的移動到具有微服務的多個云平臺和數據中心。因此，網絡也變得分散，為網絡入侵者提供了更多的攻擊面。

　　(2)網絡和安全漏洞增加：自從應用程序遷移到公共云以來，云計算提供商之間的數據和安全漏洞越來越普遍。2022年，近一半的數據泄露事件發生在云端。

　　(3)管理多集群網絡策略已經變得乏味：企業在多個Kubernetes集群和環境中部署數百個服務。網絡策略是集群的本地策略，通常不適用于多個集群。他們需要大量的定制和開發來定義和實現多集群和多云流量中的安全性和路由策略。因此，為每個服務配置和管理一致的網絡策略和防火墻規則成為一個持久而令人沮喪的過程。

　　(4)在Kubernetes中，服務到服務的連接本質上并不安全：在默認情況下，一個服務可以與集群內的另一個服務通信。因此，如果一個服務pod被黑客攻擊，網絡攻擊者可以快速輕松地攻擊該集群中的其他服務(也稱為向量攻擊)。Kubernetes不為pod或服務之間的通信提供開箱即用的加密或身份驗證。盡管Kubernetes提供了額外的安全特性，例如啟用mTLS，但這是一個復雜的過程，必須為每個服務手動實現。

　　(5)缺乏對網絡流量的可見性：如果存在安全漏洞，運維和SRE團隊應該能夠更快地對事件做出反應。跨環境的網絡流量實時可見性差成為SRE團隊及時診斷問題的瓶頸。這阻礙了他們的事件響應能力，從而導致較高的平均恢復時間(MTTR)和災難性的安全風險。

　　從理論上來說，零信任網絡(ZTN)理念解決了上述所有挑戰。在實踐中，Istio服務網格可以幫助運維團隊和SRE團隊實現跨云的零信任網絡(ZTN)和安全微服務。

　　三、Istio服務網格如何為微服務啟用零信任網絡(ZTN)

　　Istio是一款流行的開源服務網格實現軟件，它提供了一種管理和保護微服務之間通信的方法。Istio將網絡抽象為一個專用的基礎設施層，并提供對微服務之間所有通信的可見性和控制。

　　Istio的工作方式是在網格中的每個服務旁邊注入一個Envoy代理(一個小型Sidecar守護進程)(參見圖B)。Envoy是一個L4和L7代理，分別有助于確保微服務之間的安全連接和網絡連接。Istio控制平臺允許用戶管理所有這些Envoy代理，例如直接定義、級聯安全和網絡策略。

　　圖B：Istio使用Envoy代理來確保集群和云平臺之間的服務連接

　　Istio簡化了跨云平臺為微服務實施零信任網絡(ZTN)環境的過程。受到Gartner公司的零信任網絡訪問的啟發，概述了可以使用Istio實現零信任網絡的四個支柱。

　　Istio服務網格實現零信任網絡的四大支柱

　　1.使用Istio強制身份驗證

　　安全團隊需要為每個服務創建身份驗證邏輯，以驗證發送請求的用戶(人或機器)的身份。這個過程對于確保用戶的可信度是必要的。

　　在Istio中，它可以通過使用Peer Authentication和Request Authentication自定義資源(CRD)配置對等和請求認證策略來實現：

　　(1)對等身份驗證策略涉及使用mTLS對服務到服務通信進行身份驗證。也就是說，為客戶端和服務器頒發證書以驗證彼此的身份。

　　下面是一個PeerAuthentication資源示例，它對foo命名空間中的所有工作負載強制嚴格的mTLS身份驗證：

　　YAML

　　復制

　　1 apiVersion: security.istio.io/v1beta1

　　2 kind: PeerAuthentication

　　3 metadata:

　　4 name: default

　　5 namespace: foo

　　6 spec:

　　7 mtls:

　　8 mode: STRICT

　　(2)請求身份驗證策略涉及服務器確保是否允許客戶端發出請求。在這里，客戶端將把JWT (JSON Web Token)附加到服務器端身份驗證請求。

　　下面是在foo命名空間中創建的RequestAuthentication策略示例。它指定對my-app服務的傳入請求必須包含JWT，該JWT由jwtRules中提到的實體使用公鑰進行發布和驗證。

　　YAML

　　復制

　　1 apiVersion: security.istio.io/v1beta1

　　2 kind: RequestAuthentication

　　3 metadata:

　　4 name: jwt-example

　　5 namespace: foo

　　6 spec:

　　7 selector:

　　8 matchLabels:

　　9 app: my-app

　　10 jwtRules:

　　11- issuer: "https://issuer.example.com"

　　12 jwksUri: "https://issuer.example.com/keys"

　　這兩個身份驗證策略都存儲在Istio配置存儲中。

　　2.使用Istio實現授權

　　授權是驗證是否允許通過身份驗證的用戶訪問服務器(訪問控制)并執行特定的操作。持續授權可以防止惡意用戶訪問業務，從而確保其安全性和完整性。

　　Authorization Policy是另一個Istio CRD，它為部署在網格中的服務提供訪問控制。它有助于創建拒絕、允許策略，并針對入站請求執行自定義操作。Istio允許設置具有不同操作的多個策略，以實現對工作負載的細粒度訪問控制。

　　以下Authorization Policy拒絕從dev命名空間中的工作負載到foo命名空間中工作負載的POST請求。

　　YAML

　　復制

　　1 apiVersion: security.istio.io/v1beta1

　　2 kind: AuthorizationPolicy

　　3 metadata:

　　4 name: httpbin

　　5 namespace: foo

　　6 spec:

　　7 action: DENY

　　8 rules:

　　9 - from:

　　10 - source:

　　11 namespaces: ["dev"]

　　12 to:

　　13 - operation:

　　14 methods: ["POST"]

　　3.Istio的多集群和多云可見性

　　零信任網絡(ZTN)的另一個重要支柱是網絡和服務可見性。SRE團隊和運維團隊需要實時監控跨云平臺和集群邊界的微服務之間的流量。深入了解網絡將有助于SRE團隊快速識別異常的根本原因，制定解決方案并恢復應用程序。

　　Istio通過從數據和控制平臺的網格中收集以下遙測數據，提供對通信流和應用程序運行狀況的可見性。

　　(1)日志：Istio收集各種日志，例如服務日志、API日志、訪問日志、網關日志等，這將有助于理解應用程序的行為。日志還有助于更快地排除故障和診斷網絡事件。

　　(2)指標：它們有助于了解服務的實時性能，以識別異常并在運行時對其進行微調。Istio除了4個黃金指標(錯誤率、流量、延遲和飽和度)之外，還提供了許多指標。

　　(3)分布式跟蹤：它是在網格中對流經多個服務的請求進行跟蹤和可視化。分布式跟蹤有助于理解微服務之間的交互，并提供網格中服務到服務通信的整體視圖。

　　4.使用Istio進行網絡審計

　　審計是分析一個過程在一段時間內的日志，其目的是優化整個過程。審計日志為審計人員提供了對網絡活動的有價值的見解，包括每次訪問的詳細信息、使用的方法、流量模式等。這些信息對于理解數據中心和公共云內外的通信過程非常有用。

　　Istio提供了關于誰訪問(或請求)、何時訪問以及訪問什么資源的信息，這對于審計人員調查錯誤情況非常重要。審計人員需要這些信息來建議改進網絡整體性能和云原生應用程序安全性的步驟。

　　四、部署Istio以獲得更好的安全態勢

　　在微服務架構中，保護網絡和數據的挑戰將變得越來越復雜。網絡攻擊者總是在SRE團隊中的任何人有時間注意到漏洞之前搶先發現并利用它們。

　　實現零信任網絡將提供可見性和保護Kubernetes集群免受內部或外部威脅。Istio服務網格可以通過開箱即用實現零信任的能力，從前端引領這項工作。