公告 Istio 首次安全評估結果

NCC Group 進行的第三方安全審查結果。

2021 年 7 月 13 日 | 作者:Neeraj Poddar - Aspen Mesh,代表 Istio 產品安全工作組

Istio 服務網格已在各行各業廣泛採用於生產環境。該專案的成功及其在基礎架構中實施關鍵安全策略的關鍵用途,證明需要對該專案相關的安全風險進行公開且中立的評估。

為了實現此目標,Istio 社群去年與 NCC Group 簽約,對該專案進行第三方安全評估。審查的目標是「識別與 Istio 程式碼庫相關的安全問題、突出管理者常用的高風險配置,並針對安全功能是否充分解決其旨在解決的問題提供觀點」。

NCC Group 在 Istio 社群中主題專家的協作下,進行了為期五週的審查。在本部落格中,我們將檢視報告的主要發現、為實施各種修復和建議而採取的行動,以及我們針對 Istio 專案的持續安全評估和改進的行動計畫。您可以下載並閱讀未刪節版本的安全評估報告

範圍和主要發現

該評估整體評估了 Istio 的架構,以找出與安全相關的問題,重點關注 istiod (Pilot)、Ingress/Egress 閘道和 Istio 作為其資料平面代理的整體 Envoy 使用情況等關鍵元件。此外,Istio 文件,包括安全指南,也經過了正確性和清晰度的審核。該報告是針對 Istio 1.6.5 版本編寫的,從那時起,產品安全工作組發布了多個安全版本,因為新的漏洞被披露,並修復了新報告中提出的問題。

報告的一個重要結論是,稽核人員在 Istio 專案中沒有發現「重大」問題。此發現驗證了 Istio 產品安全工作組 (PSWG) 實施的持續主動安全審查和漏洞管理流程。對於報告中提出的其餘問題,PSWG 開始著手解決它們,我們很高興地報告說,所有標記為「高」的問題以及一些標記為「中/低」的問題都已在報告後發布的版本中得到解決。

該報告還針對建立強化指南提出了策略性建議,該指南現在可在我們的安全最佳實務指南中找到。這是一份綜合文件,匯集了來自 Istio 社群內部安全專家和在生產環境中執行 Istio 的產業領導者的建議。目前正在努力為在安全環境中安裝 Istio 建立一個主觀且強化的安全配置檔,但在過渡期間,我們建議使用者遵循安全最佳實務指南並配置 Istio 以滿足其安全要求。有了這些,讓我們來看看報告中提出的各種問題的分析和解決方案。

解決方案和經驗

無法保護控制平面網路通訊

該報告標記了較舊版本的 Istio 中可用的配置選項,用於控制如何保護與控制平面的通訊。自 1.7 版起,Istio 預設會保護所有控制平面通訊,並且不再需要報告中提及的許多用於管理控制平面加密的配置選項。

該報告中提到的偵錯端點預設啟用(截至 Istio 1.10),以允許使用者使用 istioctl 工具偵錯其 Istio 服務網格。可以透過將環境變數 ENABLE_DEBUG_ON_HTTP 設定為 false 來停用它,如安全最佳實務指南中所述。此外,在即將推出的版本 (1.11) 中,此偵錯端點預設會受到保護,並且需要有效的 Kubernetes 服務帳戶權杖才能取得存取權。

該報告指出了 Istio 1.6 發布的與安全相關的文件中的差距。自那時以來,我們建立了一份詳細的安全最佳實務指南,其中包含建議,以確保使用者可以安全地部署 Istio 以滿足其需求。未來,我們將繼續透過更多強化建議來擴充此文件。我們建議使用者監控指南以獲取更新。

缺少 VirtualService 閘道欄位驗證會啟用請求劫持

對於此問題,該報告使用有效的但寬鬆的閘道配置,這可能會導致請求路由不正確。與 Kubernetes RBAC 類似,Istio API(包括閘道)可以根據您的需求調整為寬鬆或嚴格。但是,該報告揭示了我們文件中與最佳實務相關的缺失連結,並指導我們的使用者保護其環境。為了解決這些問題,我們在安全最佳實務指南中新增了一個章節,其中包含安全執行閘道的步驟。特別是,強烈建議使用在閘道資源的主機規格中使用命名空間前綴的章節,以強化您的配置並防止此類請求劫持。

Ingress 閘道配置產生會啟用請求劫持

該報告指出,在閘道資源中跨命名空間使用標籤選擇閘道工作負載的預設機制時,可能會發生請求劫持。預設選擇此行為是因為它允許將管理閘道和 VirtualService 資源委託給應用程式團隊,同時允許營運團隊集中管理入口閘道工作負載,以滿足其獨特的安全需求,例如在專用節點上執行。正如報告中強調的那樣,如果您的環境中不需要此部署拓撲,則強烈建議將閘道資源與您的閘道工作負載共置,並將環境變數 PILOT_SCOPE_GATEWAY_TO_NAMESPACE 設定為 true。

請參閱閘道部署拓撲指南,以了解 Istio 社群推薦的各種部署模型。此外,如安全最佳實務指南中所述,應使用 Kubernetes RBAC 或其他原則實施機制來存取控制閘道資源建立,以確保只有授權實體才能建立它們。

其他中度和低度嚴重性問題

報告了兩個與專案內各個層級公開的偵錯資訊相關的中度嚴重性問題,這些資訊可用於存取敏感資訊或策劃阻斷服務 (DOS) 攻擊。雖然 Istio 預設啟用這些偵錯介面以進行分析或啟用像「istioctl」這樣的工具,但可以透過將環境變數 ENABLE_DEBUG_ON_HTTP 設定為 false 來停用它們,如上所述。

該報告正確地指出,Istio 提供的預設映像中安裝的各種公用程式(如 sudotcpdump 等)可能會導致權限提升攻擊。這些公用程式用於輔助對流經網格的封包進行執行階段偵錯,建議使用者在生產環境中使用這些映像的強化版本

該報告還揭示了任何基於 Sidecar 代理的服務網格實作中已知的架構限制,該實作使用 iptables 來攔截流量。此機制容易受到Sidecar 代理繞過,這對於安全環境來說是一個合理的擔憂。可以透過遵循安全最佳實務指南的縱深防禦建議來解決此問題。我們也在與 Kubernetes 社群合作研究更安全的選項。

實用性和安全性之間的權衡

您可能已經注意到評估結果的趨勢以及為了解決它們而提出的建議。Istio 提供了各種配置選項,以根據您的需求建立更安全的安裝,並且我們為使用者引入了全面的安全最佳實務指南。由於 Istio 已在生產環境中廣泛採用,因此對於我們而言,在切換到安全的預設值與升級時為現有使用者可能產生的遷移問題之間做出權衡。Istio 產品安全工作組會評估每個問題,並制定行動計畫,在讓使用者選擇安全的配置並遷移其工作負載多個版本之後,在逐案的基礎上啟用安全的預設值。

最後,在進行中立的安全評估期間和之後,我們獲得了幾個教訓。主要的一個是確保我們的安全實務能夠快速回應評估結果,更重要的是,在維護我們無中斷升級標準的同時進行安全增強。

為了繼續這項努力,我們一直歡迎在 Istio 產品安全工作組中提供回饋和參與,因此加入我們的公開會議以提出問題或了解我們正在做的事情,以保持 Istio 的安全!

分享此文章