Kubernetes叢集可觀測性與安全營運中心建置

Kubernetes 叢集的可觀測性對於維護系統穩定和安全至關重要。透過 Calico Enterprise 等工具收集 Pod、Service 和網路流量等資料，並利用 Prometheus、Grafana 等工具進行視覺化，可以深入瞭解叢集的執行狀態。Service Graph 視覺化服務間的互動關係，而網路流量視覺化則能展示不同層級的流量分佈。結合分散式追蹤技術，更能有效地分析和排查問題。此外，根據這些資料，可以建立更有效的警示系統，並與安全資訊和事件管理（SIEM）系統整合，提升 Kubernetes 叢集的安全性。更進一步，機器學習技術可以應用於警示系統，透過學習系統行為模式，動態調整閾值，提高警示準確性並減少誤報。

Kubernetes 叢集的可觀測性：資料收集、聚合與視覺化

在現代化的 Kubernetes 叢集中，可觀測性（Observability）是確保系統穩定運作的關鍵。透過對叢集內的資料進行收集、聚合、相關性分析及視覺化，我們能夠深入瞭解叢集的運作狀態，並及時發現潛在問題。本文將探討如何在 Kubernetes 叢集中實作這些功能。

資料收集

在 Kubernetes 叢集中，資料收集是可觀測性的基礎。Calico Enterprise 提供了一種有效的資料收集方式，能夠匯聚來自不同來源的資料，例如 pod、service 及網路流量等。以下是一個範例日誌：

{
  "source_labels": [
    "app=frontend",
    "pod-template-hash=6f794fbff7"
  ],
  "dest_ip": "10.57.209.29",
  "dest_name": "currencyservice-7fd6c64-t2zvl",
  "dest_name_aggr": "currencyservice-7fd6c64-*",
  "dest_namespace": "onlinebotique",
  "dest_service_namespace": "onlinebotique",
  "dest_service_name": "currencyservice",
  "dest_service_port": "grpc",
  "dest_port": 7000,
  "dest_type": "wep",
  "dest_labels": [
    "app=currencyservice",
    "pod-template-hash=7fd6c64"
  ],
  "proto": "tcp",
  "action": "allow",
  "reporter": "src",
  "policies": [
    "1|platform|platform.allow-kube-dns|pass",
    "2|__PROFILE__|__PROFILE__.kns.hipstershop|allow",
    "0|security|security.pass|pass"
  ],
  "bytes_in": 68437,
  "bytes_out": 81760,
  "num_flows": 1,
  "num_flows_started": 0,
  "num_flows_completed": 0,
  "packets_in": 656,
  "packets_out": 861,
  "http_requests_allowed_in": 0,
  "http_requests_denied_in": 0,
  "process_name": "wrk:worker_0",
  "num_process_names": 1,
  "process_id": "26446",
  "num_process_ids": 1,
  "tcp_mean_send_congestion_window": 10,
  "tcp_min_send_congestion_window": 10,
  "tcp_mean_smooth_rtt": 9303,
  "tcp_max_smooth_rtt": 13537,
  "tcp_mean_min_rtt": 107,
  "tcp_max_min_rtt": 107,
  "tcp_mean_mss": 1408,
  "tcp_min_mss": 1408,
  "tcp_total_retransmissions": 0,
  "tcp_lost_packets": 0,
  "tcp_unrecovered_to": 0,
  "host": "gke-v2y0ly8k-logging-default-pool-e0c7499d-76z8",
  "@timestamp": 1623033334000
}

資料解密：

此 JSON 物件包含了一個網路流量的日誌記錄，主要欄位如下：

source_labels 和 dest_labels：來源和目的地的標籤，用於識別相關的 pod 和服務。
dest_ip、dest_name、dest_namespace：目的地的 IP、名稱及名稱空間。
proto、action：協定型別（TCP）和執行的動作（允許或拒絕）。
policies：影響該流量的網路策略。
bytes_in、bytes_out、packets_in、packets_out：傳輸的位元組和封包數量。
process_name、process_id：相關的處理程式名稱和 ID。
TCP 相關的統計資料，如平均傳送擁塞視窗、平滑 RTT 等。

這個日誌範例展示了 Calico Enterprise 如何匯聚來自不同 pod 和服務的資料，並將其與網路策略和處理程式資訊進行關聯。

資料視覺化

資料視覺化是可觀測性的重要組成部分。透過視覺化的方式，我們可以更直觀地瞭解叢集的運作狀態。常見的視覺化工具包括 Prometheus、Grafana、Datadog 和 Calico Enterprise 等。

Service Graph

Service Graph 是用於表示 Kubernetes 叢集中服務之間互動關係的圖表。它能夠清晰地展示服務之間的依賴關係和網路活動。例如，圖 5-4 是 Google 微服務線上商城應用的 Service Graph 表示。

此圖示展示了線上商城應用中各服務之間的互動關係。

資料解密：

Service Graph 能夠動態展示 Kubernetes 中各服務之間的互動情況。節點代表服務或 pod，邊緣表示網路活動和策略執行的結果。使用者可以點選某個服務以檢視詳細的日誌和監控資料。

網路流量視覺化

網路流量視覺化是另一種重要的視覺化方式。圖 5-6 所示的環形視覺化圖表能夠展示不同聚合層級的網路流量。

詳細說明：

在這個視覺化圖表中：

最外層的環代表名稱空間及其內的流量。
中間層的環代表服務層級的流量。
最內層的環代表支援該服務的 pod 的流量。

右側的面板提供篩選和詳細資訊，用於顯示所選範圍內的流量和策略執行情況。

分析與故障排除

在完成資料收集和視覺化後，我們可以進一步利用這些資料進行深入分析與故障排除。例如，分散式追蹤（Distributed Tracing）技術能夠幫助我們追蹤單一使用者請求在多個微服務之間的處理流程，從而快速定位問題所在。

分散式追蹤的重要性：

在微服務架構中，使用者請求往往需要多個服務協同處理。分散式追蹤技術能夠提供完整的請求處理鏈路檢視，幫助開發人員快速定位效能瓶頸或錯誤來源。

實作可觀測性：提升 Kubernetes 叢集的安全性

在前一章中，我們討論瞭如何在 Kubernetes 叢集上實作可觀測性，包括日誌收集、分散式追蹤和網路流量分析。本章將著重於如何利用可觀測性平台來提升 Kubernetes 叢集的安全性，並介紹相關的最佳實務。

警示系統的建置

要建立有效的警示系統，必須具備以下功能：

自動化查詢多種日誌資料來源（例如 Kubernetes 活動日誌、網路日誌、應用程式日誌、DNS 日誌等）
支援狀態機制，用於在指定時間內偵測到指定次數的門檻違規事件
能夠將可行的警示匯出至外部的安全資訊和事件管理（SIEM）系統，以便納入企業的事件回應流程

實作警示系統

apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: example-alert-rule
spec:
  groups:
  - name: example-alert-rules
    rules:
    - alert: ExampleAlert
      expr: rate(example_metric[5m]) > 10
      for: 5m
      labels:
        severity: critical
      annotations:
        summary: "Example alert triggered"

內容解密：

此 YAML 程式碼定義了一個 Prometheus 警示規則，用於監控 example_metric 的變化率。當該變化率在 5 分鐘內超過 10 時，觸發 ExampleAlert 警示。該警示具有 critical 的嚴重性，並包含了一個簡短的摘要說明。

安全營運中心（SOC）的參考實作

一個安全營運中心（SOC）是企業用於監控和管理安全事件的中央樞紐。透過整合可觀測性平台，SOC 可以更有效地偵測和回應 Kubernetes 叢集中的安全威脅。

使用 UEBA 提升安全性

使用者和實體行為分析（UEBA）是一種利用機器學習技術來分析使用者和實體行為的技術，可以幫助偵測異常行為和潛在的安全威脅。

重點整理

警示系統的建置對於 Kubernetes 叢集的安全性至關重要
SOC 可以透過整合可觀測性平台來提升安全性
UEBA 可以幫助偵測異常行為和潛在的安全威脅

未來，我們可以預期可觀測性平台將繼續演進，提供更多先進的功能和技術來提升 Kubernetes 叢集的安全性。企業應該持續關注最新的技術發展，並根據其需求調整其安全策略。

警示系統的最佳實踐與機器學習的應用

在 Kubernetes 叢集中，警示系統的組態對於維護系統的穩定性和安全性至關重要。Figure 6-2 展示了一個警示查詢組態的範例。在這個查詢中，我們可以結合 Kubernetes 的後設資料（如標籤）與網路流量活動（如目的地、協定）和策略判決（如動作）來定義警示。這種靈活性使得我們能夠根據叢集的具體需求建立有效的警示機制。

警示查詢的靈活性

在 Figure 6-2 的範例中，我們可以看到查詢組態允許使用 Kubernetes 後設資料與網路活動和策略判決結合。這種組合提供了極大的靈活性，能夠根據叢集的實際情況定義出有效的警示。例如，我們可以根據特定的標籤過濾網路流量，或者根據策略判決結果觸發警示。

現有的警示系統

現有的警示系統，如雲端供應商提供的警示系統，以及 Datadog、Sysdig 和 Calico Enterprise 等工具，都提供了 Kubernetes 原生的警示功能。這些系統在檢測和報告系統異常方面表現出色，尤其是在系統行為可預測且閾值易於定義的情況下。

機器學習在警示系統中的應用

然而，當系統行為複雜多變時，傳統的根據閾值的警示系統可能會出現誤報或漏報的情況。這時，機器學習技術可以發揮重要作用。機器學習能夠「學習」系統的行為模式，並動態調整閾值，從而提高警示的準確性並減少誤報。

機器學習的基本技術

機器學習中有幾種關鍵技術可以用於警示系統：

監督式學習：透過標記測試資料來訓練系統，使其能夠對新資料進行分類別和預測。
非監督式學習：使用演算法檢測和分類別未標記資料中的模式。由於 Kubernetes 叢集中的實體（如 Pod）具有短暫性，非監督式學習特別適合於檢測異常。
基線法：建立一個模型，不斷預測給定指標的值，並檢測與預期值的偏差。這種方法可以用於自動定義閾值並對異常進行警示。

機器學習任務範例

以下是一些利用機器學習進行異常檢測的任務範例：

IP 掃描檢測：檢測叢集中向多個目的地傳送封包的 Pod，可能指示攻擊者已控制某個 Pod 並正在進行偵察。
埠掃描檢測：檢測向單一目的地多個埠傳送封包的 Pod，同樣可能指示攻擊者正在進行偵察。
服務位元組異常：檢測接收或傳送異常大量資料的服務，可能指示拒絕服務攻擊或資料外洩。
處理程式重新啟動異常：檢測具有過多處理程式重新啟動的 Pod，可能指示資源問題或攻擊。
DNS 延遲異常：檢測 DNS 請求延遲過高的客戶端，可能指示拒絕服務攻擊。
L7 延遲異常：檢測 L7 請求延遲過高的 Pod，可能指示拒絕服務攻擊或其他攻擊。
HTTP 連線尖峰異常：檢測接收過多 HTTP 連線的服務，可能指示拒絕服務攻擊。

內容解密：

本文主要介紹了在 Kubernetes 環境下，如何利用機器學習技術提升警示系統的有效性。
傳統的警示系統依賴於預先定義的閾值，但在複雜多變的 Kubernetes 環境中，這種方法可能導致誤報或漏報。
機器學習技術，尤其是非監督式學習和基線法，可以用於動態調整閾值，提高警示的準確性。
文章列舉了多個利用機器學習進行異常檢測的任務範例，包括 IP 掃描檢測、埠掃描檢測等。
這些技術和方法的應用，可以顯著提高 Kubernetes 環境下的安全性和穩定性。

使用機器學習實作 Kubernetes 安全營運中心

在現代的雲端運算環境中，Kubernetes 已成為容器編配事實上的標準。隨著 Kubernetes 叢集規模和複雜度的增加，如何確保叢集的安全性和可觀察性成為了一個重要的課題。本篇文章將探討如何利用機器學習技術實作 Kubernetes 安全營運中心（Security Operations Center, SOC）。

為什麼需要安全營運中心？

安全營運中心是用於檢測和回應安全事件的集中管理平台。對於根據 Kubernetes 的 SaaS 服務，SOC 可以幫助企業即時監控和回應叢集中的安全威脅。透過整合日誌記錄、監控和警示功能，SOC 可以提供全方位的安全防護。

根據 Google Cloud 的 SOC 實作範例

圖 6-3：Google Cloud 中的 SOC 實作範例

此圖示展示瞭如何在 Google Cloud 中建立一個 SOC。首先，Kubernetes 叢集的日誌被收集並傳送到 Google Cloud Operations Suite。然後，這些日誌被用於生成警示，並透過 OpsGenie 路由到各種通知工具，如 SIEM、Slack 和 PagerDuty。

內容解密：

Kubernetes 叢集：這是執行在 Google Cloud 上的 Kubernetes 叢集，包含多個名稱空間，每個名稱空間代表一個租戶。
Google Cloud Operations Suite：這是一個全面的維運解決方案，提供日誌記錄、監控和警示功能。
OpsGenie：這是一個警示管理工具，用於路由和管理警示通知。
SIEM、Slack、PagerDuty 和 JIRA：這些是常見的安全和維運工具，用於處理和回應安全事件。

使用 Kubernetes 原生平台建立 SOC

雖然根據特定雲端服務供應商的 SOC 實作方案很有效，但它們通常與特定的雲平台繫結。為了建立一個更具彈性和跨雲支援能力的 SOC，我們可以使用 Kubernetes 原生的可觀察性和安全平台。

圖 6-4：使用 Kubernetes 原生平台的 SOC

此圖示展示瞭如何使用 Kubernetes 原生平台建立一個 SOC。這種方案更具彈性，可以佈署在不同的雲環境或本地資料中心。

內容解密：

Kubernetes 原生可觀察性平台：這是一個根據 Kubernetes 的可觀察性解決方案，可以提供日誌記錄、監控和警示功能。
警示管理工具：這是一個用於管理和路由警示通知的工具，可以與各種安全和維運工具整合。

使用者和實體行為分析（UEBA）

使用者和實體行為分析（UEBA）是一種利用機器學習和人工智慧技術來檢測異常行為的方法。在 Kubernetes 環境中，UEBA 可以用於檢測服務或 Pod 的異常行為。

圖 6-5：Kubernetes 服務的行為分析

@startuml
skinparam backgroundColor #FEFEFE
skinparam componentStyle rectangle

title Kubernetes叢集可觀測性與安全營運中心建置

package "Kubernetes Cluster" {
    package "Control Plane" {
        component [API Server] as api
        component [Controller Manager] as cm
        component [Scheduler] as sched
        database [etcd] as etcd
    }

    package "Worker Nodes" {
        component [Kubelet] as kubelet
        component [Kube-proxy] as proxy
        package "Pods" {
            component [Container 1] as c1
            component [Container 2] as c2
        }
    }
}

api --> etcd : 儲存狀態
api --> cm : 控制迴圈
api --> sched : 調度決策
api --> kubelet : 指令下達
kubelet --> c1
kubelet --> c2
proxy --> c1 : 網路代理
proxy --> c2

note right of api
  核心 API 入口
  所有操作經由此處
end note

@enduml

此圖示展示了一個 Kubernetes 服務與其他元件的互動關係。透過分析這些互動關係，我們可以建立一個服務的行為模型，並檢測異常行為。

內容解密：

Kubernetes 服務：這是一個執行在 Kubernetes 叢集中的服務，與其他元件（如 API 伺服器、資料儲存、Ingress 資源等）互動。
UEBA 引擎：這是一個利用機器學習技術來分析服務行為並檢測異常的引擎。
日誌收集和分析：UEBA 引擎收集來自各種資料來源的日誌，並對其進行分析和關聯，以生成相關的日誌。

玄貓 BlackCat

技術愛好者，專注於分享程式開發、雲端技術與 AI 應用的心得體會。