Istio的安全機制防護

• 2019 年 12 月 11 日
• 筆記

一、Istio安全簡介

Istio於北京時間7月31日晚24點發布1.0版本，首次可用於生產環境。目前Istio的安全機制主要包括基於RBAC的訪問控制、認證策略、雙向TLS認證、服務健康檢查等幾個方面[1]，Istio 提供了安全操作指南以便於驗證其安全機制，感興趣的同學可以通過訪問官方網站學習。

眾所周知，將傳統的單體應用拆分為一個個微服務固然帶來了各種好處，包括更好的靈活性、可伸縮性，重用性，但微服務也同樣面臨著特殊的安全需求，如下所示：

（1） 為了抵制中間人攻擊，需要對流量進行加密。

（2） 為了提供靈活的服務訪問控制，服務間需要相互TLS和更細粒度的訪問策略。

（3） 為了審核誰在什麼時候做了什麼，需要安全審計工具。

面對這些需求Istio嘗試提供全面的安全解決方案，目前已提供了身份驗證策略，透明的TLS加密以及授權和審計工具。藉助這些安全機制，Istio推動如下安全目標：

（1） 默認的安全性：無需修改即可保證應用程式程式碼和架構的安全性。

（2） 縱深防禦：與現有的安全系統結合併提供多層防禦。

（3） 零信任網路：在不受信任的網路上構建安全解決方案。

需要說明的是，傳統基礎設施層實現縱深防禦和零信任網路是通過網路層面的層層隔離和訪問控制實現的，而微服務架構是工作在平台層，所以是通過應用層的認證授權的策略實現的。

Istio的安全防護機制如圖1所示：

圖1 Istio的安全機制

目前Istio已提供了一套高級別的安全架構，其安全性涉及Istio的多個重要組件：

（1）Citadel：用於管理密鑰和證書

（2）sidecar和perimeter proxies：實現客戶端和服務端之間的安全通訊。

（3）Pilot：將身份驗證策略和安全命名資訊分派給代理。

（4）Mixer：用於管理授權和審計。

Istio的安全架構如圖2所示：

圖2 Istio的安全架構

Istio的安全解決方案主要通過在微服務所屬容器旁部署一個Sidecar容器來對服務的安全進行防護。主要分為以下三個方面：

二、認證策略

Istio的認證策略主要由兩部分組成，分別為Peer策略（TLS相互認證）和Origin策略（驗證發出請求源）。執行過程通常是使用Kubernetes中的自定義資源定義（CustomResourceDefinitions，CRD）去定義策略相關配置，然後由Istio的Pilot組件分發到Sidecar容器中去執行。認證策略架構如圖3所示:

圖3 Istio認證策略架構

三、服務間TLS身份驗證

Istio使用TLS為每個微服務提供強大的身份驗證機制，並通過角色管理來實現跨集群和雲的功能。此外，TLS認證機制還確保了服務與服務之間的通訊安全。

Istio官方給出的身份認證架構如圖4所示，主要分為身份、密鑰管理和通訊安全三個組件。此圖描述了服務frontend以服務賬戶frontend-team運行，服務backend以服務賬戶backend-team運行。它們的通訊原來是沒有進行加密的，但Istio在不修改程式碼的前提下，依託Envoy形成的服務網格，直接在客戶端Envoy和服務端Envoy之間進行通訊加密。

圖4 Istio TLS身份認證架構圖

四、基於RBAC的訪問控制

Istio為Service Mesh中的微服務提供基於角色的訪問控制（Role-Based Access Control，RBAC）。Istio提供了基於角色的語法讓用戶填寫yaml文件，部署後Istio將策略保存至Istio Config存儲中。Pilot監控著Istio訪問控制策略的變更，若有更改，將獲取更新後的訪問控制策略，同時將策略分發到Envoy代理中，每個Envoy代理都運行一個授權引擎，當請求到達Envoy代理時，授權引擎根據策略評估當前請求的上下文，並返回授權結果，ALLOW或DENY。訪問控制過程如圖5所示：

圖5基於RBAC的訪問控制架構圖

五、總結

以上為Istio的安全機制簡介，Istio的出現不但解決了第一代微服務的痛點，在安全性上也是非常有保障的。

[1] https://istio.io/docs/tasks/security/

內容編輯：雲安全實驗室 浦明 責任編輯：肖晴