Splunk 的全面網路安全

隨著數十種可用的網路安全工具，很容易找到說明如何透過為流量增加身分、策略和可觀察性來提高網路安全性的教學和演示。但通常較不清楚的是這些工具如何協同運作，為您的生產網路提供全面的安全性。您需要多少工具？您的網路何時才夠安全？

這篇文章將探討 Splunk 用於保護其 Kubernetes 網路基礎架構的工具和實踐，從 VPC 設計和連線開始，一路到基於 HTTP 請求的安全性。在此過程中，我們將了解為您的雲原生堆疊提供全面網路安全需要哪些步驟、這些工具如何協同運作，以及其中一些工具可以在哪些方面改進。Splunk 使用各種工具來保護其網路，包括

• AWS 功能
• Kubernetes
• Istio
• Envoy
• Aviatrix

關於 Splunk 的使用案例

Splunk 是一家科技公司，提供一個用於收集、分析和視覺化各種來源產生的資料的平台。它主要用於通過網頁式介面搜索、監視和分析機器產生的大數據。Splunk Cloud 是一項將 Splunk 內部基礎架構遷移到雲原生架構的計劃。如今，Splunk Cloud 由全球各地 AWS 和 GCP 中的 35 多個完全複製的叢集組成。

保護第 3/4 層：AWS、Aviatrix 和 Kubernetes

在 Splunk Cloud 中，我們使用一種稱為「cookie cutter VPC」的模式，其中每個叢集都配置有自己的 VPC，具有用於 Pod 和節點 IP 的相同私有子網、用於進出公用網際網路的公用子網，以及用於叢集之間流量的內部子網。這使來自不同叢集的 Pod 和節點完全隔離，同時允許叢集外部的流量在公用和內部子網中執行特定規則。此外，當利用許多叢集時，此模式避免了 RFC 1918 私有 IP 耗盡的可能性。

在每個 VPC 中，設定網路 ACL 和安全組，以限制連線到絕對需要的程度。例如，我們限制與我們的 Ingress 節點（將部署 Envoy Ingress 閘道）的公用連線。除了普通的東/西和北/南流量外，Splunk 還有每個叢集都需要存取的共用服務。Aviatrix 用於提供重疊的 VPC 存取，同時也執行一些高階安全性規則（每個網域的區隔）。

Splunk 堆疊中的下一個安全層是 Kubernetes 本身。驗證 Webhook 用於防止部署允許叢集中不安全流量的 K8S 物件（通常圍繞 NLB 和服務）。Splunk 還依賴 NetworkPolicies 來保護和限制 Pod 到 Pod 的連線。

保護第 7 層：Istio

Splunk 使用 Istio 基於每個請求的詳細資訊在應用程式層強制執行策略。Istio 還會發出遙測資料（指標、日誌、追蹤），這對於驗證請求層級的安全性非常有用。

Istio 注入 Envoy Sidecar 的主要優點之一是 Istio 可以為整個網格提供傳輸中加密，而無需對應用程式進行任何修改。應用程式發送純文字 HTTP 請求，但 Envoy Sidecar 會攔截流量並實施相互 TLS 加密，以防止攔截或修改。

Istio 管理 Splunk 的 Ingress 閘道，這些閘道接收來自公用和內部 NLB 的流量。閘道由平台團隊管理，並在 Istio Gateway 命名空間中執行，允許使用者插入它們，但不能修改它們。閘道服務還配備了憑證，以預設強制執行 TLS，並且驗證 Webhook 確保服務只能連線到它們自己主機名稱的閘道。此外，閘道會在流量影響應用程式 Pod 之前，在 Ingress 處強制執行請求驗證。

由於 Istio 和相關的 K8S 物件配置相對複雜，Splunk 建立了一個抽象層，這是一個為服務配置所有內容的控制器，包括虛擬服務、目標規則、閘道、憑證等等。它會設定直接指向正確 NLB 的 DNS。這是一個端對端網路部署的一鍵式解決方案。對於更複雜的使用案例，服務團隊仍然可以繞過抽象層並直接配置這些設定。

痛點

雖然 Splunk 的架構滿足了我們的許多需求，但仍有一些痛點值得討論。Istio 的運作方式是建立與應用程式 Pod 一樣多的 Envoy Sidecar，這是一種低效率的資源利用方式。此外，當特定應用程式對其 Sidecar 有獨特的需求時，例如額外的 CPU 或記憶體，如果不調整網格中所有 Sidecar 的設定，則很難調整這些設定。Istio Sidecar 注入涉及大量「魔法」，使用變異 Webhook 在建立時向每個 Pod 添加 Sidecar 容器，這意味著這些 Pod 不再與它們對應的部署匹配。此外，注入只能在 Pod 建立時發生，這意味著每當 Sidecar 版本或參數更新時，所有 Pod 都必須重新啟動，才能獲得新的設定。總體而言，這種「魔法」使得在生產環境中執行服務網格變得複雜，並為您的應用程式增加了很大的操作不確定性。

Istio 專案意識到這些限制，並認為 Istio 的新 Ambient 模式將大幅改善這些限制。在此模式下，身分和加密等第 4 層結構將由在節點上執行的 Daemon 應用，但不會在與應用程式相同的 Pod 中。第 7 層功能仍將由 Envoy 處理，但 Envoy 將作為其自身部署的一部分在相鄰的 Pod 中執行，而不是依賴 Sidecar 注入的「魔法」。應用程式 Pod 在 Ambient 模式下不會以任何方式修改，這應該為服務網格操作增加相當大的可預測性。預計 Ambient 模式將在 Istio 1.18 中達到 Alpha 品質。

結論

有了 Splunk Cloud 中網路安全的所有這些層，回頭檢查請求在遍歷這些層時的生命週期是很有幫助的。當用戶端發送請求時，它們首先連線到 NLB，這將被 VPC ACL 允許或阻止。然後，NLB 將請求代理到其中一個 Ingress 節點，該節點會終止 TLS 並在第 7 層檢查請求，選擇允許或阻止該請求。然後，Envoy 閘道使用 ExtAuthZ 驗證請求，以確保已正確驗證，並符合配額限制，然後才允許進入叢集。接下來，Envoy 閘道會將請求代理到上游，Kubernetes 的網路策略會再次生效，以確保允許此代理。工作負載上的上游 Sidecar 會檢查第 7 層請求，如果允許，它將解密請求並以純文字形式發送到工作負載。

在滿足這家大型企業公司的可擴展性需求的同時，保護 Splunk 的雲原生網路堆疊需要在每一層進行仔細的安全性規劃。

雖然在堆疊中的每一層應用身分、可觀察性和策略原則起初可能看起來是多餘的，但每一層都能彌補其他層的缺點，以便這些層共同形成一道嚴密而有效的屏障，防止未經授權的存取。

如果您有興趣更深入地了解 Splunk 的網路安全堆疊，您可以觀看我們的雲原生 SecurityCon 簡報。