安全模型

8 分鐘閱讀

本文旨在描述 Istio 各個組件的安全性態勢，以及可能的攻擊如何影響系統。

組件

Istio 帶有多種可選組件，本文將涵蓋這些組件。如需高層次概述，請參閱Istio 架構。請注意，Istio 部署具有高度的彈性；在下方，我們將主要假設最壞的情況。

Istiod

Istiod 作為 Istio 的核心控制平面組件，通常扮演著XDS 服務組件的角色，以及網格的mTLS 憑證授權機構。

Istiod 被認為是一個高度特權的組件，類似於 Kubernetes API 伺服器本身。

它具有很高的 Kubernetes RBAC 權限，通常包括 Secret 讀取權限和 webhook 寫入權限。
當作為 CA 時，它可以佈建任意憑證。
當作為 XDS 控制平面時，它可以程式化代理來執行任意行為。

因此，叢集的安全性與 Istiod 的安全性緊密相關。遵循有關 Istiod 存取的Kubernetes 安全最佳實務至關重要。

Istio CNI 外掛程式

Istio 可以選擇性地使用Istio CNI 外掛程式 DaemonSet進行部署。此 DaemonSet 負責在 Istio 中設定網路規則，以確保流量根據需要透明地重新導向。這是下方討論的 istio-init 容器的替代方案。

由於 CNI DaemonSet 會修改節點上的網路規則，因此需要提升的 securityContext。但是，與Istiod不同，這是一個節點本機權限。其影響在下方討論。

由於這將設定網路所需的提升權限整合到單一 Pod 中，而不是每個 Pod，因此通常建議使用此選項。

Sidecar 代理

Istio 可以選擇性地在應用程式旁邊部署一個 Sidecar 代理。

Sidecar 代理需要程式化網路，以將所有流量導向代理。這可以使用 Istio CNI 外掛程式完成，或透過在 Pod 上部署 initContainer (istio-init) 來完成 (如果未部署 CNI 外掛程式，則會自動執行此操作)。istio-init 容器需要 NET_ADMIN 和 NET_RAW 功能。但是，這些功能僅在初始化期間存在 - 主要的 Sidecar 容器完全沒有特權。

此外，Sidecar 代理根本不需要任何關聯的 Kubernetes RBAC 權限。

每個 Sidecar 代理都已獲授權為關聯的 Pod 服務帳戶請求憑證。

閘道和航點

閘道和航點充當獨立的代理部署。與Sidecar不同，它們不需要任何網路修改，因此不需要任何特權。

這些組件使用它們自己的服務帳戶執行，與應用程式身分不同。

Ztunnel

Ztunnel充當節點級別的代理。此任務需要 NET_ADMIN、SYS_ADMIN 和 NET_RAW 功能。與Istio CNI 外掛程式類似，這些僅是節點本機權限。Ztunnel 沒有任何關聯的 Kubernetes RBAC 權限。

Ztunnel 已獲授權為在相同節點上執行的 Pod 的任何服務帳戶請求憑證。與kubelet類似，這明確不允許請求任意憑證。這再次確保這些權限僅為節點本機。

流量捕獲屬性

當 Pod 註冊到網格時，所有傳入的 TCP 流量都將重新導向至代理。這包括 mTLS/HBONE流量和純文字流量。在將流量轉發到工作負載之前，將強制執行工作負載的任何適用原則。

但是，Istio 目前不保證傳出流量將重新導向至代理。請參閱流量捕獲限制。因此，如果需要輸出原則，則必須謹慎遵循保護輸出流量的步驟。

相互 TLS 屬性

相互 TLS 為 Istio 的許多安全性態勢提供了基礎。以下說明相互 TLS 為 Istio 安全性態勢提供的各種屬性。

憑證授權機構

Istio 開箱即用，帶有自己的憑證授權機構。

預設情況下，CA 允許根據以下任何選項對客戶端進行驗證

Kubernetes JWT 權杖，受眾為 istio-ca，透過 Kubernetes TokenReview 驗證。這是 Kubernetes Pod 中的預設方法。
現有的相互 TLS 憑證。
自訂 JWT 權杖，使用 OIDC 驗證 (需要設定)。

CA 只會發出為已驗證客戶端的身分請求的憑證。

Istio 也可以與各種第三方 CA 整合；請參閱它們的任何安全性文件，以了解有關它們行為方式的更多資訊。

客戶端 mTLS

在 Sidecar 模式下，客戶端 Sidecar 將在連線到偵測到支援 mTLS 的服務時自動使用 TLS。也可以明確設定。請注意，此自動偵測依賴 Istio 將流量與服務關聯。不支援的流量類型或設定範圍可以防止此情況。

當連線到後端時，允許的身分集是在服務層級根據所有後端的身分的聯集計算的。

伺服器 mTLS

預設情況下，Istio 將接受 mTLS 和非 mTLS 流量 (通常稱為「寬容模式」)。使用者可以透過撰寫需要 mTLS 的 PeerAuthentication 或 AuthorizationPolicy 規則選擇強制執行嚴格的執行。

當建立 mTLS 連線時，將驗證對等憑證。此外，還會驗證對等身分是否在相同的信任網域中。若要驗證僅允許特定身分，可以使用 AuthorizationPolicy。

探索的入侵類型

根據上述概述，我們將考慮如果系統的各個部分遭到入侵，對叢集的影響。在現實世界中，任何安全攻擊都有各種不同的變數

執行有多容易
需要哪些先前的權限
可以被利用的頻率
影響是什麼 (完全遠端執行、阻斷服務等)。

在本文中，我們將主要考慮最壞的情況：遭到入侵的組件意味著攻擊者具有完整的遠端程式碼執行功能。

工作負載入侵

在這種情況下，應用程式工作負載 (Pod) 遭到入侵。

Pod可能有權限存取其服務帳戶權杖。如果這樣，工作負載入侵可以從單一 Pod 橫向移動到入侵整個服務帳戶。

在 Sidecar 模型中，代理與 Pod 共置，並在相同的信任界限內執行。遭到入侵的應用程式可以透過管理 API 或其他介面竄改代理，包括外洩私密金鑰材料，允許其他代理模擬工作負載。應假設遭到入侵的工作負載也包括對 Sidecar 代理的入侵。

因此，遭到入侵的工作負載可能

傳送任意流量，無論是否具有相互 TLS。這些可能會繞過任何代理設定，甚至完全繞過代理。請注意，Istio 不提供基於輸出的授權原則，因此不會發生輸出授權原則繞過的情況。
接受已指定給應用程式的流量。它可能會繞過在 Sidecar 代理中設定的原則。

這裡的重點是，雖然遭到入侵的工作負載可能會惡意運作，但這不會讓它們能夠繞過其他工作負載中的原則。

Istio 提供了各種功能，可以限制此類入侵的影響

可觀察性功能可用於識別攻擊。
原則可用於限制工作負載可以傳送或接收的流量類型。

代理入侵 - Sidecar

在這種情況下，Sidecar 代理遭到入侵。由於 Sidecar 和應用程式位於相同的信任網域中，因此這在功能上等同於工作負載入侵。

代理入侵 - 航點

在這個情境中，航點代理（waypoint proxy）遭到入侵。雖然航點本身沒有任何可供駭客利用的權限，但它們確實（可能）為許多不同的服務和工作負載提供服務。一旦航點遭到入侵，它將接收所有這些服務和工作負載的流量，並可以檢視、修改或丟棄這些流量。

Istio 提供了設定航點部署粒度的彈性。如果使用者需要更強的隔離性，可以考慮部署更為隔離的航點。

由於航點是以與其服務的應用程式不同的身分執行，因此航點遭到入侵並不代表使用者的應用程式可以被冒充。

代理入侵 - Ztunnel

在這個情境中，ztunnel 代理遭到入侵。

一旦 ztunnel 遭到入侵，攻擊者就可以控制節點的網路連線。

Ztunnel 可以存取在其節點上執行的每個應用程式的私鑰材料。一旦 ztunnel 遭到入侵，這些私鑰材料可能會被洩漏並在其他地方使用。然而，橫向移動到共同部署工作負載之外的身分是不可能的；每個 ztunnel 僅被授權存取在其節點上執行的工作負載的憑證，這限制了遭入侵的 ztunnel 的影響範圍。

節點入侵

在這個情境中，Kubernetes 節點遭到入侵。Kubernetes 和 Istio 的設計都旨在限制單一節點入侵的影響範圍，確保單一節點的入侵不會導致叢集範圍的入侵。

然而，攻擊者確實可以完全控制在該節點上執行的任何工作負載。例如，它可以入侵任何共同部署的航點、本地ztunnel、任何邊車代理（sidecar）、任何共同部署的Istiod 實例等等。

叢集 (API 伺服器) 入侵

Kubernetes API 伺服器的入侵實際上意味著整個叢集和網格都遭到入侵。與大多數其他攻擊途徑不同，Istio 在控制此類攻擊的影響範圍方面無能為力。遭到入侵的 API 伺服器會讓駭客完全控制叢集，包括在任意 Pod 上執行 kubectl exec、移除任何 Istio AuthorizationPolicies，甚至完全解除安裝 Istio 等操作。

Istiod 入侵

Istiod 的入侵通常會導致與API 伺服器入侵相同的結果。Istiod 是一個高度特權的元件，應受到嚴格保護。遵循安全最佳實務對於維護安全的叢集至關重要。