使用 Istio 保護您的微服務
本文轉載自微信公眾號「新鈦云服」，作者祝祥 。轉載本文請聯系新鈦云服公眾號。
介紹
Istio 是一個開源項目，旨在管理云上微服務之間的通信。它獨立于平臺，但通常且主要與 Kubernetes 一起使用。Istio 提供了多項關鍵功能，例如流量管理、安全性和可觀察性。
在本文中，我們將重點介紹 Istio 的安全能力，包括增強認證、透明 TLS 加密、身份驗證和授權。我們將 Istio 部署在 Kubernetes 集群上，并逐步介紹 Istio 安全功能，討論這些功能如何保護您的服務。
示例
我們使用 Istio 提供的示例應用 Bookinfo[1] 來演示本文中 Istio 的功能。讓我們來看看 Istio 安全和 Bookinfo 的架構。
ISTIO 安全架構
Istio 安全涉及多個組件;下圖顯示了該架構。在控制平面的 Istiod 組件中，我們有一個 CA(Certificate Authority)來管理證書，相關配置通過 API 服務器發送到數據平面(Envoy)。Envoy 作為策略執行點 (PEP) 來保護網格中客戶端和服務器之間或網格外部和內部之間的通信安全。
Bookinfo應用架構
Bookinfo 應用程序分為四個獨立的微服務：
- productpage：調用詳細信息和評論微服務
- details：包含書籍詳細信息
- eviews：調用 ratings 微服務生成書評
- ratings：包含伴隨書評的排名信息
評論微服務共有三個版本;productpage 以循環方式訪問這些版本：
· 版本 v1 不調用ratings服務。
· 版本 v2 調用ratings服務并將每個評級顯示為 1 到 5 顆黑星。
· 版本 v3 調用ratings服務并將每個評級顯示為 1 到 5 顆紅星。
該應用程序的端到端架構如下所示。這些是沒有 Istio sidecar 部署的原始純服務。
ISTIO 認證
如果您已經安裝了 Istio，則無需對應用程序進行任何更改即可運行示例。或者，您可以簡單地在支持 Istio 的環境中配置和運行服務，并在每個服務旁邊注入 Envoy sidecar。生成的部署如下所示：
這里我們特意部署了沒有 sidecar 的 review-v2 和其他有 sidecar 的服務。這可以通過設置 Kubernetes 命名空間標簽“istio-injection=enabled/disabled”輕松控制。一旦我們為 Pod 注入一個 sidecar 或者只是設置一個單一的邊緣代理作為入口網關，Istio 身份就會生效。
Istio 身份模型使用一流的服務身份來確定請求來源的身份。在 Kubernetes 上，Istio 使用 Kubernetes 服務帳戶作為身份。下圖展示了 Istio 的身份配置工作流程。
- 啟動一個注入了 Istio 的 Pod，它還會啟動一個 Envoy 實例作為 Pod 的 sidecar。
- 當工作負載啟動時，Envoy 通過 Envoy secret發現服務 (SDS) API 從 Istio 代理請求證書。
- Istio 代理將證書簽名請求 (CSR) 及其憑據 (JWT) 發送到 istiod 進行簽名。
- Istio 代理將從 istiod 收到的以 SPIFFE 格式簽名的證書通過 Envoy SDS API 發送給 Envoy。
這里的證書是x.509，SPIFFE格式的URL作為x.509證書的擴展字段進行識別。SPIFFE 是開源的;k8s環境下Istio身份的格式類似于“spiffe://
雙向 TLS
Istio 支持雙向 TLS 來加密服務之間傳輸的數據。在 Bookinfo 應用程序中，所有服務最初都是基于純 HTTP 協議相互通信的，其中數據沒有加密。當一個工作負載使用雙向 TLS 認證策略向另一個工作負載發送請求時，工作負載和 sidecar 之間的數據仍然是純文本的，而客戶端 Envoy 和服務器端 Envoy 建立雙向 TLS 連接。
對等認證
應用對等身份驗證策略(如上所示)后，Istio 會自動將兩個 PEP 之間的所有流量升級為雙向 TLS。由于默認情況下啟用了 Istio 的自動 mTLS，因此仍然可以通過 HTTP 訪問 Reviews-v2。Istio 中的 Auto-mTLS 有助于確定客戶端 Sidecar 可以發送的流量類型：
如果配置了 DestinationRule，則信任它
如果服務器有 sidecar 并允許 mTLS，發送 mTLS – review-v1 & v3
否則，發送純文本 – review-v2
對等身份驗證僅定義服務器sidecar可以接收哪種類型的流量。Reviews-v2 沒有 sidecar，所以客戶端向它發送純文本。服務器端默認處于 PERMISSIVE 模式，這意味著服務器端可以接受純文本和 mTLS。這在開始將集群與服務網格集成時非常有用，因為操作員通常無法同時為所有客戶端安裝 Istio sidecar，或者甚至沒有權限在某些客戶端上這樣做。
目的規則
與對等身份驗證相比，目標規則定義了客戶端 Sidecar 可以發送的流量類型。應用目標規則策略(如上所示)后，review-v2 無法再訪問，因為目標規則限制 productpage sidecar 發送 mTLS 流量，而 review-v2 只能接收純文本。
保護入口流量
Istio 支持通過入口網關將安全的 HTTPS 服務暴露給外部流量，因此無需更改內部協議。它總共支持四種模式來在入口啟用 TLS。SIMPLE/MUTUAL 和 ISTIO_MUTUAL 對傳入的請求執行 TLS 終止;它們用于配置對 HTTP 服務的
HTTPS 入口訪問。PASSTHROUGH 和 AUTO_PASSTHROUGH 僅按原樣傳遞入口流量，而不是使用 TLS 終止。
授權入口流量
添加要求最終用戶 JWT 用于入口網關的請求身份驗證策略。如果您在授權標頭中提供令牌(其隱式默認位置)，則 Istio 將使用公鑰集驗證令牌，并在不記名令牌無效時拒絕請求。但是，接受沒有令牌的請求。
要拒絕沒有有效令牌的請求，請添加一個 AuthorizationPolicy 規則，為具有請求主體的請求指定 ALLOW 操作，在上面的示例中顯示為 requestPrincipals。requestPrincipals 僅在提供有效的 JWT 令牌時可用。因此，該規則只允許具有有效令牌的請求。
應用RequestAuthentication，如上圖：
- 使用有效的 JWT 令牌請求 √
- 請求沒有 JWT 令牌 √
- 使用無效的 JWT 令牌請求 ×
應用AuthorizationPolicy，如上圖
- 使用有效的 JWT 令牌請求 √
- 沒有 JWT 令牌的請求 ×
- 使用無效的 JWT 令牌請求 ×
網格流量中的授權
AuthorizationPolicy 不僅可以應用于入口網關，還可以用于控制網格內部的訪問。授權策略規范包括選擇器、操作和規則列表：
· 選擇器字段指定策略的目標
· action 字段指定是允許還是拒絕請求;默認值為“允許”
· 規則指定何時觸發動作
- 規則中的 from 字段指定請求的來源
- 規則中的 to 字段指定請求的操作
- when 字段指定應用規則所需的條件
如果應用拒絕所有 AuthorizationPolicy，則默認命名空間下的服務之間的所有請求都將被拒絕。如果您隨后應用 productpage-viewer 如下例所示，它允許對 productpage 服務進行“GET”操作。
與productpage-viewer AuthorizationPolicy相比，reviews-viewer在spec規則的source字段多了一項配置;它指定只允許具有“[“cluster.local/ns/default/sa/bookinfo-productpage”]”服務帳戶的服務發送“GET”請求。一一應用其他 AuthorizationPolicy 并測試產品頁面。Bookinfo 服務提供的不同信息都會再次出現在您的網頁上。圖片
概括：Istio 自動提供強大的識別功能。它還具有雙向 TLS，可對流量進行加密以抵御中間人攻擊。Auto-mTLS 幫助您加入 Istio，PeerAuthentication 和 DestinationRule 簡化了對配置進行細微調整的過程。此外，Istio 提供了靈活的服務訪問控制，因此您可以使用 RequestAuthentication、AuthorizationPolicy 等來設置細粒度的訪問策略。
參考
· Istio 官方文檔：https ://istio.io/latest/docs/
· https://istio.io/latest/docs/examples/bookinfo/
原文
https://01.org/blogs/luyaozhong/2021/secure-your-microservices-istio
