大規模安全性原則效能測試

概述

Istio 具有廣泛的安全性原則，可以輕鬆配置到服務系統中。隨著應用原則數量的增加，了解系統的延遲、記憶體使用量和 CPU 使用率之間的關係非常重要。

這篇部落格文章將介紹常見的安全性原則使用案例，以及安全性原則的數量或安全性原則中特定規則的數量如何影響請求的整體延遲。

設定

安全性原則種類繁多，而且這些原則還有更多的組合。我們將介紹 6 個最常用的測試案例。

以下測試案例在一個環境中執行，該環境包含一個 Fortio 用戶端向 Fortio 伺服器發送請求，基準線是未部署 Envoy sidecar。以下資料是使用 Istio 效能基準測試工具收集的。

在這些測試案例中，請求要么不符合任何規則，要么只符合安全性原則中的最後一個規則。這確保了 RBAC 篩選器應用於所有原則規則，並且在檢視所有原則之前，永遠不會比對到任何原則規則。儘管這不一定會發生在您自己的系統中，但此原則設定為每個測試案例提供了最壞效能的資料。

測試案例

1. 相互 TLS STRICT 與純文字。

2. 一個具有可變數量主體規則以及一個 PeerAuthentication 原則的單一授權原則。主體規則取決於 PeerAuthentication 原則是否已應用於系統。

3. 一個具有可變數量 requestPrincipal 規則以及一個 RequestAuthentication 原則的單一授權原則。 requestPrincipal 取決於 RequestAuthentication 原則是否已應用於系統。

4. 一個具有可變數量 paths 與 sourceIP 規則的單一授權原則。

5. 由單一路徑或 sourceIP 規則組成，數量可變的授權原則。

6. 一個具有可變數量 JWTRules 規則的單一 RequestAuthentication 原則。

資料

每個測試的 y 軸是以毫秒為單位的延遲，而 x 軸是並行連線數。每個圖表的 x 軸包含 3 個數據點，分別代表小負載（qps=100，conn=8）、中等負載（qps=500，conn=32）和大負載（qps=1000，conn=64）。

MTLS 與純文字 AuthZ mTLS SourcePrincipals AuthZ JWT RequestPrincipal AuthZ sourceIP AuthZ paths RequestAuthN JWT Issuer 可變 AuthZ

在較低的負載下，MTLS 模式 STRICT 和純文字之間的延遲差異非常小。隨著 `qps` 和 `conn` 的增加，使用 MTLS STRICT 的請求延遲會增加。在較大負載下增加的額外延遲，與從沒有 sidecar 到純文字中有 sidecar 的增加相比是微不足道的。

結論

• 總體而言，添加安全性原則不會對系統增加相對較高的負擔。增加最多延遲的原則包括

  1. 具有 JWTRules 規則的授權原則。

  2. 具有 requestPrincipal 規則的授權原則。

  3. 具有主體規則的授權原則。

• 在較低的負載下（具有較低 qps 和 conn 的請求），大多數原則的延遲差異很小。

• 即使原則很大，Envoy proxy sidecar 增加的延遲也比大多數原則要多。

• 極大原則的延遲增加與新增 Envoy proxy sidecar 相比，與沒有 sidecar 的延遲增加相對相似。

• 兩個不同的測試確定 sourceIP 規則比路徑規則略慢。

如果您有興趣建立自己的大規模安全性原則並使用它們執行效能測試，請參閱 效能基準測試工具 README。

如果您有興趣閱讀更多有關安全性原則測試的資訊，請參閱我們的設計文件。如果您還沒有訪問權限，可以加入 Istio 團隊雲端硬碟。