云原生專欄大綱

TLS 和 mTLS

TLS（Transport Layer Security）和 mTLS（mutual TLS）都是用于加密通信的協議，用于保護數據在網絡上的傳輸安全。它們在保護通信方面有一些區別：

1. TLS（Transport Layer Security）：
   • TLS 是一種加密通信協議，用于在網絡上安全地傳輸數據。它用于建立安全的通信通道，確保數據在傳輸過程中不被篡改或竊取。
   • TLS 通常用于客戶端和服務器之間的通信，并且只要求服務器端提供證書，客戶端驗證服務器身份。
   • 在 Web 安全中，HTTPS（HTTP over TLS）就是使用 TLS 來加密 HTTP 通信的協議。
2. mTLS（mutual TLS）：
   • mTLS 是 TLS 的一種擴展，也稱為雙向 TLS 或雙向認證。它要求通信雙方（客戶端和服務器）都提供證書，進行相互驗證身份。
   • 在 mTLS 中，不僅服務器驗證客戶端的身份，客戶端也驗證服務器的身份。這種雙向驗證確保了通信的雙方都是可信的，并且加強了通信的安全性。

主要區別在于 TLS 通常是單向驗證，而 mTLS 是雙向驗證。mTLS 提供了更高級別的安全性，因為它不僅驗證服務器的身份，還驗證客戶端的身份，確保了通信的完整性和安全性。
在網絡安全領域，mTLS 通常用于要求更嚴格的安全標準的場景，如微服務之間的通信、API 訪問控制等。通過使用 mTLS，可以確保通信雙方的身份驗證和通信數據的加密，提高了通信的安全性和可靠性。

TLS 和 mTLS使用場景

TLS（Transport Layer Security）和 mTLS（mutual TLS）在網絡通信中有不同的使用場景，根據安全需求和通信模型的不同，選擇合適的加密方式非常重要：
TLS 使用場景：

1. Web通信：TLS 在 Web 通信中廣泛應用，用于加密 HTTP 通信，形成 HTTPS 協議，保護 Web 應用的數據傳輸安全。
2. 客戶端-服務器通信：在傳統的客戶端-服務器模型中，服務器通常會提供證書，客戶端驗證服務器的身份，確保通信的安全性。
3. 加密數據傳輸：TLS 可用于保護數據在網絡上的傳輸，確保數據在傳輸過程中不被篡改或竊取。
4. 保護隱私數據：適用于需要保護用戶隱私數據的應用場景，如登錄、支付等敏感操作。

mTLS 使用場景：

1. 微服務通信：在微服務架構中，各個服務之間的通信可能需要更嚴格的安全性要求，mTLS 可用于確保服務之間的雙向身份驗證和通信加密。
2. API 訪問控制：在 API 訪問控制中，服務端可以要求客戶端提供證書進行身份驗證，確保只有授權的客戶端可以訪問 API。
3. 云原生環境：在容器化和云原生環境中，mTLS 可用于保護容器間的通信，確保容器之間的安全通信。
4. 內部通信：適用于內部系統或服務之間的通信，要求更高級別的安全性和身份驗證。

總的來說，TLS 適用于大多數常規的加密通信場景，而 mTLS 則適用于對通信安全性要求更高、需要雙向身份驗證的場景，如微服務架構、API 訪問控制等。選擇合適的加密方式取決于您的安全需求和通信模型。

TLS 加密通信的流程

1. 服務器向受信任的 CA（證書管理機構）申請并獲得證書（X.509 證書）；
2. 客戶端向服務端發起請求，其中包含客戶端支持的 TLS 版本和密碼組合等信息；
3. 服務器回應客戶端請求并附上數字證書；
4. 客戶端驗證證書的狀態、有效期和數字簽名等信息，確認服務器的身份；
5. 客戶端和服務器使用共享秘鑰實現加密通信；

參考：TLS 握手期間會發生什么？
寫給 Kubernetes 工程師的 mTLS 指南 | 云原生資料庫

終止 TLS

TLS 終止（TLS Termination）指的是在將 TLS 加密流量傳遞給 Web 服務器之前對其進行解密的過程。將 TLS 流量卸載到入口網關或專用設備上，可以提高 Web 應用的性能，同時確保加密流量的安全性。一般運行在集群入口處，當流量到達入口處時實施 TLS 終止，入口與集群內服務器之間的通信將直接使用 HTTP 明文，這樣可以提高服務性能。

Istio 默認在入口網關處終止 TLS，然后再為網格內的服務開啟 mTLS。你也可以讓流量直通（passthrough）到后端服務處理，例如：

apiVersion: networking.istio.io/v1beta1
kind: Gateway
metadata:name: sample-gateway
spec:servers:- port:number: 443name: httpsprotocol: HTTPStls:mode: PASSTHROUGH

什么時候用 mTLS？

互聯網客戶端對 Web 服務的訪問，一般使用單向 TLS，即只需要服務端提供身份證明，而不關心客戶端的身份。當你需要驗證客戶端身份時，使用單向 TLS 可以使用密碼、token、雙因子認證等方式。不過這樣的認證方式需要應用程序內部支持，而雙向 TLS 是運行在應用程序之外的，不需要多應用邏輯進行修改。

1. 實施 mTLS 的服務間需要交換證書，當服務數量變大時，就需要管理大量的證書，這需要消耗大量的精力，使用服務網格可以幫助你實現自動 mTLS，徹底解決證書管理的難題。
2. 微服務通信：在微服務架構中，各個服務之間的通信可能需要更嚴格的安全性要求，mTLS 可用于確保服務之間的雙向身份驗證和通信加密。
3. API 訪問控制：在 API 訪問控制中，服務端可以要求客戶端提供證書進行身份驗證，確保只有授權的客戶端可以訪問 API。
4. 云原生環境：在容器化和云原生環境中，mTLS 可用于保護容器間的通信，確保容器之間的安全通信。
5. 內部通信：適用于內部系統或服務之間的通信，要求更高級別的安全性和身份驗證。
   

什么時候不用 mTLS？

雖然 mTLS 是確保云原生應用程序服務間通信安全的首選協議，但是應用 mTLS 需要完成復雜的對稱加密、解密過程，這將非常耗時且消耗大量的 CPU 資源。
對于某些安全級別不高的流量，如果我們在流量入口處終止 TLS，并網格內部僅對針對性的服務開啟 mTLS，就可以加快請求響應和減少計算資源消耗。

流量加密

Istio流量主要包含入口流量和內部流量，入口流量是需要TLS進行加密的，加密解密過程是需要消耗CPU資源的，若是集群規模比較大內部服務多，內部流量

1. 外部入站流量 這是被 Sidecar 捕獲的來自外部客戶端的流量。 如果客戶端在網格外面，該流量可能被 Istio 雙向 TLS 加密。 Sidecar 默認配置 PERMISSIVE （寬容）模式：接受 mTLS 和 non-mTLS 的流量。 該模式能夠變更為 STRICT （嚴格）模式，該模式下的流量流量必須是 mTLS；或者變更為 DISABLE （禁用）模式， 該模式下的流量必須為明文。mTLS 模式使用 PeerAuthentication資源配置。
2. 內部入站流量 這是從 Sidecar 流出并引入您的應用服務的流量。流量會保持原樣轉發。 注意這并不意味著它總是明文狀態，Sidecar 可能也通過 TLS 連接。 這只意味著一個新的 TLS 連接將不會從 Sidecar 中產生。
3. 內部出站流量 這是被 Sidecar 攔截的來自您的應用服務的流量。 您的應用可能發送明文或者 TLS 的流量。 如果自動選擇協議已開啟，Istio 將能夠自動地選擇協議。 否則您可以在目標服務內使用端口名手動指定協議。
4. 外部出站流量 這是離開 Sidecar 到一些外部目標的流量。流量會報錯原樣轉發，也可以啟動一個 TLS 連接（mTLS 或者標準 TLS）。 這可以通過 DestinationRule資源中的 trafficPolicy 來控制使用的 TLS 模式。 模式設置為 DISABLE 將發生明文，而 SIMPLE、MUTUAL 和 ISTIO_MUTUAL 模式將會發起一個 TLS 連接。

關鍵要點是：

• PeerAuthentication 用于配置 Sidecar 接收的 mTLS 流量類型。
• DestinationRule 用于配置 Sidecar 發送的 TLS 流量類型。
• 端口名，或者自動選擇協議，決定 sidecar 解析流量的協議。
  

入口流量加密

理解 TLS 配置
作為入站請求的一部分，網關必須對流量進行解碼才能應用路由規則。 網關根據 Gateway資源中的服務配置解碼。 例如，如果入站連接是明文的 HTTP，則端口協議配置成 HTTP：

apiVersion: networking.istio.io/v1beta1
kind: Gateway
...servers:- port:number: 80name: httpprotocol: HTTP

同樣，對于原始 TCP 流量，協議將設置為 TCP。
對于 TLS 連接，還有更多選項：

1. 封裝了什么協議？ 如果連接是 HTTPS，服務協議應該配置成 HTTPS。 反之，對于使用 TLS 封裝的原始 TCP 連接，協議應設置為 TLS。
2. TLS 連接是終止還是通過？ 對于直通流量，將 TLS 模式字段配置為 PASSTHROUGH：

apiVersion: networking.istio.io/v1beta1
kind: Gateway
...servers:- port:number: 443name: httpsprotocol: HTTPStls:mode: PASSTHROUGH

在這種模式下，Istio 將根據 SNI 信息進行路由并將請求按原樣轉發到目的地。

3. 是否應該使用雙向 TLS ？ 相互 TLS 可以通過 TLS 模式 MUTUAL 進行配置。配置后，客戶端證書將根據配置的 caCertificates 或 credentialName 請求和驗證：

apiVersion: networking.istio.io/v1beta1
kind: Gateway
...servers:- port:number: 443name: httpsprotocol: HTTPStls:mode: MUTUALcaCertificates: ...

內部流量加密

如何理解 Istio 中的 mTLS 流量加密？
tio 的對等認證默認使用 PERMISSIVE 模式，自動將 mTLS 流量發送到這些工作負載，將純文本流量發送到沒有 sidecar 的工作負載。在將 Kubernetes 服務納入 Istio 網格后，為了防止服務無法通過 mTLS，我們可以先使用 PERMISSIVE 模式。當我想為某些服務開啟嚴格的 mTLS 模式時，可以使用以下兩種方式之一：

• 使用 PeerAuthentication 定義流量如何在 sidecar 之間傳輸；
• 使用 DestinationRule 定義流量路由策略中的 TLS 設置；
  

PeerAuthentication 為工作負載設置 mTLS

你可以使用 namespace 和 selector 指定某個命名空間下的某個工作負載開啟嚴格的 mTLS。例如下面的配置：

apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:name: foo-peer-policynamespace: default
spec:selector:matchLabels:app: reviewsmtls:mode: STRICT

你也可以給安裝 Istio 的命名空間 istio-system 設置嚴格的 mTLS，那樣會為網格中的所有服務開啟嚴格的 mTLS，詳細步驟請參考 Istio 文檔 。

PeerAuthentication 中指定對目標工作負載實施的 mTLS 模式。對等認證支持以下模式：

• PERMISSIVE：默認值，工作負載可接受雙向 TLS 或純文本流量；
• STRICT：工作負載僅接受 mTLS 流量；
• DISABLE：禁用 mTLS。從安全角度來看，除非你有自己的安全解決方案，否則不應禁用 mTLS；
• UNSET：從父級繼承，優先級為服務特定 > 命名空間范圍 > 網格范圍的設置；
  

DestinationRule 為工作負載設置 mTLS

DestinationRule 用于設置流量路由策略，例如負載均衡、異常點檢測、TLS 設置等。其中 TLS 設置中包含多種模式 ，使用 ISTIO_MUTUAL 模式可以為工作負載開啟 Istio 的自動 TLS，如下所示。

apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:name: reviewsnamespace: default
spec:host: reviewstrafficPolicy:tls:mode: ISTIO_MUTUAL

安全最佳實戰

參考官網：安全最佳實踐 安全策略示例
安全中通常會匹配那些路徑能訪問，通常這些訪問路徑研發人員才知道，若全是交給技術設施人員比較吃力，此處小編建議使用SpringcloudGateway網關進行路由規則的配置。istio人員只需配置限制的域名，流量加密鑒權等。在內部服務對安全要求較高的服務上加mTLS，網關入口終止TLS。