深入瞭解 Kube-Audit 日誌的重要性與應用

– 19 分鐘閱讀

為何 Kubernetes 稽核日誌是你安全策略中不可或缺的一環

隨著雲端平台與容器技術的快速發展，Kubernetes 已成為許多企業的基礎設施核心。然而，強大的技術也伴隨著複雜的安全挑戰。在我多年管理大型 Kubernetes 叢集的經驗中，我發現許多團隊往往忽略了一個內建但功能強大的安全工具：Kubernetes 稽核日誌（Kube-Audit logs）。

當談到 Kubernetes 的安全監控時，市場上確實存在許多專業工具，但今天我想聚焦在這個被低估但實用性極高的原生功能上。透過妥善設定和利用 Kube-Audit 日誌，你可以大幅提升叢集的安全性、透明度與問題追蹤能力。

Kubernetes 的多層日誌架構解析

在深入瞭解 Kube-Audit 日誌前，我們先來認識 Kubernetes 的日誌生態系統。透過理解不同層級的日誌，你將能更有效地監控和排除系統問題。

系統日誌（System Logs）

系統日誌記錄了與作業系統和 Kubernetes 服務元件相關的事件。這包括：

  • Kubelet 服務日誌
  • API 伺服器日誌
  • 排程器（Scheduler）日誌
  • etcd 資料函式庫
  • 一般性事件（如 Pod 啟動或停止）

這些日誌提供了叢集核心元件的運作狀況，是排除系統層級問題的關鍵資源。

稽核日誌（Audit Logs）

稽核日誌專門記錄 API 伺服器的請求和回應，讓管理員能完整追蹤系統中的操作序列及其結果。正如我們將在本文深入討論的，這是安全分析和合規監控的重要工具。

應用程式日誌（Application Logs）

這些是由容器內執行的應用程式產生的日誌，內容完全取決於開發者的設計。常見的記錄包括：

  • 錯誤和異常情況
  • 除錯資訊
  • 交易稽核記錄
  • 效能指標

Pod 日誌（Pod Logs）

Pod 日誌提供特定 Pod 的運作資訊，包括錯誤訊息和警告。這些日誌對於排除應用程式層級的問題非常有用。

事件日誌（Event Logs）

事件日誌記錄叢集中的重要活動，如：

  • Pod 的建立與銷毀
  • 資源分配錯誤
  • 節點狀態變化

指標資料（Metrics）

雖然不是傳統意義上的日誌，但指標資料提供了 Kubernetes 系統和應用程式的效能資訊，包括資源使用率和請求處理時間等關鍵資料。

Kube-Audit 日誌：被低估的安全利器

在我協助多家企業建立 Kubernetes 安全架構的過程中，發現許多專業人員並不完全瞭解 Kube-Audit 日誌的價值，甚至不清楚如何有效利用它們。這可能是因為它們的設定需要一些額外的設定工作，而與產生的資料量可能相當龐大。

Kube-Audit 日誌的運作原理

Kubernetes 中的所有請求都必須透過 API 伺服器處理。稽核日誌的功能就是記錄這些請求，提供一個完整的操作追蹤機制。這是透過在主節點（Master Node）上放置一個稱為「稽核政策」（Audit Policy）的設定檔案來實作的。

Kubernetes API 伺服器請求流程

在單一主節點的小型叢集中，所有請求都會經過該節點的 API 伺服器。但在多主節點架構下，請求會分散到不同的 API 伺服器。由於無法精確控制特定類別的請求路由到特定的 API 伺服器，因此所有主節點必須設定相同的稽核政策。

稽核政策如何回答關鍵安全問題

許多技術文章提到，稽核政策可以幫助回答以下問題：

  • 什麼事件發生了？
  • 何時發生的？
  • 誰發起了這個操作？
  • 在哪裡觀察到這個事件？
  • 操作是從哪裡發起的？

讓我們探討這些問題，並瞭解稽核日誌如何在實際環境中提供這些答案。

稽核政策不僅可以追蹤使用者的操作，還能監控系統中由服務帳號（Service Account）執行的自動化事件。

想像一個場景：根據你的設定，Pod 應該每五分鐘建立一次。但在日誌中，你發現建立頻率是每三秒一次。透過稽核日誌，你可以迅速識別這種異常行為的原因——可能是錯誤的設定、預設值被觸發，或者是外部幹擾。

稽核日誌通常以 JSON 格式記錄，但也支援字串格式。以下是一個實際的稽核日誌範例，讓我們看它如何回答上述問題：

{
  "_index": "kube-audit-shturval-kir- secured-2024.11.13",
  "_id": "9FF5A5E6-D5C2-0395-74AE-79AFCD496435",
  "_version": 1,
  "_score": null,
  "_source": {
    "@timestamp": "2023-08-12T13:28:19.954Z",
    "kind": "Event",
    "stageTimestamp": "2023-08-12T13:28:19.953446Z",
    "requestReceivedTimestamp": "2023-08-12T13:28:19.948513Z",
    "responseStatus": {
      "code": 200,
      "metadata": {}
    },
    "auditID": "08b10265-1ec7-4de2-8376-abec7701ae98",
    "userAgent": "sh-backend-api/v0.0.0 (linux/amd64) kubernetes/$Format",
    "stage": "ResponseComplete",
    "objectRef": {
      "resource": "secrets",
      "apiVersion": "v1",
      "name": "sh.helm.release.v1.shturval-cert-manager.v1",
      "namespace": "cert-manager"
    },
    "requestURI": "/api/v1/namespaces/cert-manager/secrets/sh.helm.release.v1.shturval-cert-manager.v1?timeout=1m0s",
    "sourceIPs": [
      "10.XX.XXX.214"
    ],
    "apiVersion": "audit.k8s.io/v1",
    "verb": "get",
    "username": "shturval:a.kirichenko"
    },
    "level": "Metadata"
  },
  "fields": {
    "requestReceivedTimestamp": [
      "2023-08-12T13:28:19.948Z"
    ],
    "stageTimestamp": [
      "2023-08-12T13:28:19.953Z"
    ],
    "@timestamp": [
      "2023-08-12T13:28:19.954Z"
    ]
}

從這個日誌中，我們可以清楚看到：

  • 什麼事件發生了？ - 使用者執行了一個 get 操作（"verb": "get"），查詢了一個名為 sh.helm.release.v1.shturval-cert-manager.v1 的金鑰（Secret）。
  • 何時發生的？ - 事件發生在 2023-08-12T13:28:19.948Z（requestReceivedTimestamp）。
  • 誰發起了這個操作？ - 使用者 shturval:a.kirichenko（"username": "shturval:a.kirichenko"）。
  • 在哪裡觀察到這個事件？ - 在 cert-manager 名稱空間（"namespace": "cert-manager"）。
  • 操作是從哪裡發起的？ - 來源 IP 是 10.XX.XXX.214（"sourceIPs": ["10.XX.XXX.214"]）。

這個簡單的例子展示了稽核日誌如何提供完整的操作追蹤能力。在實際的安全事件調查中，這些資訊是無價的。

在我的實務經驗中，當一個生產環境突然出現異常時，稽核日誌往往是最快找出原因的方法。無論是意外的設定變更、未授權的存取嘗試，還是自動化指令碼的錯誤行為，稽核日誌都能提供關鍵線索。

下一部分，我們將探討如何設定和設定 Kube-Audit 日誌，以及如何根據不同需求調整稽核政策。

Kubernetes 稽核日誌系統：深入解析與實踐

稽核日誌的基本結構

每條稽核日誌記錄都包含關鍵元素，這些元素共同構成了 Kubernetes 系統中請求處理的完整記錄。這些元素包括：

  • 事件識別碼：用於唯一標識每個稽核事件
  • 處理階段：指示請求在系統中的處理進度
  • 請求路徑（requestURI）：記錄客戶端請求的資源路徑
  • 日誌等級（request）：標示記錄的詳細程度
  • 使用者資訊（user）：記錄發起請求的使用者身份
  • 操作類別（verb）：說明使用者執行的動作類別
  • 時間戳記：記錄請求發生的確切時間
  • 結果狀態：指示請求處理的最終結果

這種結構化的日誌設計使管理員能夠全面掌握系統中發生的所有操作，特別是在安全稽核和問題診斷方面提供了寶貴的資訊來源。

稽核政策的架構設計

Kubernetes 的稽核功能透過一個集中的政策檔案來管理，這個 YAML 格式的檔案定義了系統需要記錄哪些操作以及如何記錄。每條政策規則主要描述四個關鍵導向：

  1. 請求的目標物件
  2. 目標資源所屬的 API 群組
  3. 需要監控的資源集合
  4. 特定的限制條件（如有）

值得注意的是，稽核政策屬於 Kubernetes 的非公開 API 類別，與 kubeconfig (v1)、ImagePolicy API 等類別似。當政策檔案不包含任何規則時，kube-API 伺服器會將其視為無效，並拒絕掛載：

E0427 11:18:56.916457 1 run.go:74] "command failed" err="loading audit policy file:
loaded illegalpolicy with 0 rules: from file /etc/kubernetes/audit_policy.yaml"

另外，政策檔案中的 YAML 語法錯誤可能導致 API 伺服器完全停止運作，因此在設定稽核政策時需要謹慎。

稽核階段詳解

稽核系統透過不同的處理階段來捕捉請求生命週期中的各個時刻。雖然無法直接指定在哪個階段記錄資料，但可以透過設定來排除特定階段。主要階段包括：

  • 請求接收（Request Received）：稽核過程的初始階段，記錄請求來源和時間等基本資訊，此時系統尚未知道請求的執行結果。
  • 回應開始（Response Started）：適用於長時間執行的請求（如 watch 操作），此時標頭已傳送但回應內容尚未完成。
  • 回應完成（Response Complete）：在回應內容完全傳送後開始，對於使用變異型 Webhook 的情況特別有用。
  • 異常（Panic）：當 Kube-Audit 遇到意外錯誤導致當機時觸發，會產生包含錯誤詳情的日誌。這種情況可能是由於許可權不足或無法連線到 API 伺服器等問題引起。

雖然這些階段通常按順序執行，但系統故障可能導致跳過某些階段。例如，如果在 Response Started 階段發生當機，系統可能直接跳到 Panic 階段而略過 Response Complete。可以使用 omitStages 引數指定需要跳過的階段。

規則設定詳解

稽核規則的設定主要按 API 群組劃分，包含以下關鍵元素：

  • 群組（Group）：資源所屬的 API 群組
  • 等級（Level）：資料記錄的詳細程度：
    • None：預設值，不記錄比對此規則的操作，通常用於從通用規則中排除特定操作
    • Metadata：記錄核心資訊（使用者、操作類別、資源、作用域和結果），但不包含請求內容，適合處理敏感資訊
    • Request：包含 Metadata 層級的所有資訊外，還記錄請求內容，適用於需要監控資源建立和修改的場景
    • RequestResponse：最完整的記錄方式，包含請求和回應的完整內容
  • 使用者篩選（users）：特定使用者的操作記錄
  • 使用者群組篩選（userGroups）：特定使用者群組的操作記錄
  • 名稱空間篩選（namespaces）：特定名稱空間內的操作記錄
  • 操作類別篩選（verbs）：特定操作類別（如 create、update、patch、delete、watch、get）
  • 非資源 URL 篩選（nonResourceURLs）：非資源類別的請求路徑（如 /metrics、/healthz*）
  • 資源篩選（resources）：特定資源類別的操作記錄

若未指定特定篩選條件，則系統會記錄所有相關操作。例如，若未指定操作類別，則會記錄所有與篩選資源相關的操作；若未指定資源，則會記錄所有屬於指定 API 群組的資源操作。

規則的順序也非常重要，系統會按順序評估規則，先比對的規則優先生效。例如，如果先指定記錄所有對 Secret 的操作，然後再指定某些服務帳戶不需記錄，後一條規則可能不會生效。

另外，Kubernetes 預設會在 managed fields 中增加系統欄位，可能導致日誌量大幅增加。可以透過設定 omitManagedFields: true 來解決這個問題。

政策範例實戰

以下是一個全面的稽核政策範例，展示了各種常見場景的設定方法：

apiVersion: audit.k8s.io/v1
kind: Policy
# 不在 RequestReceived 階段生成稽核事件
omitStages:
  - "RequestReceived"
rules:
  # 以 RequestResponse 等級記錄 Pod 變更
  - level: RequestResponse
    resources:
    - group: ""
      # "pods" 資源不比對 pods 的任何子資源請求，這與 RBAC 政策一致
      resources: ["pods"]
  
  # 以 Metadata 等級記錄 "pods/log", "pods/status"
  - level: Metadata
    resources:
    - group: ""
      resources: ["pods/log", "pods/status"]

  # 不記錄對名為 "controller-leader" 的 configmap 的請求
  - level: None
    resources:
    - group: ""
      resources: ["configmaps"]
      resourceNames: ["controller-leader"]

  # 不記錄 "system:kube-proxy" 對 endpoints 或 services 的 watch 請求
  - level: None
    users: ["system:kube-proxy"]
    verbs: ["watch"]
    resources:
    - group: "" # 核心 API 群組
      resources: ["endpoints", "services"]

  # 不記錄已認證請求到特定非資源 URL 路徑
  - level: None
    userGroups: ["system:authenticated"]
    nonResourceURLs:
    - "/api*" # 萬用字元比對
    - "/version"

  # 記錄 kube-system 名稱空間中 configmap 變更的請求內容
  - level: Request
    resources:
    - group: "" # 核心 API 群組
      resources: ["configmaps"]
    # 此規則僅適用於 "kube-system" 名稱空間中的資源
    # 空字串 "" 可用於選擇非名稱空間資源
    namespaces: ["kube-system"]

  # 以 Metadata 等級記錄所有其他名稱空間中的 configmap 和 secret 變更
  - level: Metadata
    resources:
    - group: "" # 核心 API 群組
      resources: ["secrets", "configmaps"]

  # 以 Request 等級記錄核心和擴充套件群組中的所有其他資源
  - level: Request
    resources:
    - group: "" # 核心 API 群組
    - group: "extensions" # 不應包含群組版本

  # 一個捕捉所有其他請求的規則，以 Metadata 等級記錄
  - level: Metadata
    # 符合此規則的長時間執行請求（如 watches）不會在 RequestReceived 中生成稽核事件
    omitStages:
      - "RequestReceived"

這個政策範例涵蓋了各種常見場景，從敏感資源的詳細記錄到系統操作的過濾排除。透過這種分層設計，管理員可以在保持系統效能的同時取得關鍵的安全稽核資訊。

稽核系統的實際應用

在實際維運環境中，稽核系統扮演著多重角色：

  1. 安全合規：滿足組織的合規要求，記錄誰在何時存取了哪些敏感資源
  2. 問題診斷：當系統出現異常時，詳細的操作記錄可以幫助快速定位問題
  3. 行為分析：透過分析操作模式，可以識別潛在的安全威脅或異常行為
  4. 系統最佳化：瞭解資源存取模式，有助於進行系統最佳化和資源規劃

在設計稽核策略時，需要平衡記錄詳細程度與系統效能。過於詳細的記錄可能導致大量儲存消耗和系統負擔，而過於簡略的記錄則可能無法滿足安全需求。因此，建議根據實際需求和資源限制，採用分層的記錄策略：對敏感操作進行詳細記錄，對常規操作進行適度記錄。

Kubernetes 稽核系統提供了強大而靈活的機制，使管理員能夠全面掌握叢集中發生的所有重要操作。透過精心設計的稽核政策，可以在不影響系統效能的前提下，實作全面的安全監控與問題診斷能力。隨著雲原生應用的普及，這種能力將在確保系統安全與穩定執行方面發揮越來越重要的作用。

Kubernetes稽核日誌：設定策略與儲存方案全面解析

容器平台的稽核政策基礎

在公開檔案中，容器化平台「Shturval」建議使用基本稽核政策。您可以下載免費的社群版平台，親自體驗其運作方式。當安裝具有增強安全設定的叢集時，稽核政策會自動掛載。

稽核日誌儲存策略：避免潛在風險

稽核日誌預設並不會自動記錄。要啟用此功能，必須在叢集的所有主節點上設定政策清單，並指定日誌儲存位置。每個叢集只能設定一個稽核政策。

有兩種主要的日誌儲存方式：一是存放在叢集內部，二是透過Webhook傳送到外部系統。這些引數需在Kube-API伺服器的設定檔中設定。

讓我們深入分析各種方法，然後比較它們的優缺點。

Kube-API伺服器上有34個標誌可用於微調日誌記錄或重定向。每個標誌的設定價值需要根據環境個別評估。

Webhook後端實作

Kubernetes官方檔案中提供了使用Webhook傳送日誌的設定方法。這種方法僅適用於需要傳送日誌而不需要內部儲存的情況。資料透過HTTP協定傳送。

實作時需要一個可用的HTTP伺服器（例如在叢集的某個容器中）和Webhook的設定。Webhook可以用任何支援HTTP的程式語言編寫，HTTP伺服器的地址需要直接寫入稽核政策中。

優點：

  • 節省本地儲存空間
  • etcd不必競爭寫入請求資源

缺點：

  • 接收服務不可用時增加資料丟失風險
  • 增加API伺服器負載
  • 叢集負載變更時需定期調整引數，避免緩衝區溢位導致日誌丟失

引數調整所需的監控指標：

# 用於追蹤稽核子系統狀態的指標
apiserver_audit_event_total    # 已匯出稽核事件總數
apiserver_audit_error_total    # 因匯出錯誤而丟棄的事件總數

日誌後端實作

日誌直接寫入叢集本地儲存。可以設定寫入引數和日誌輪替。

優點：

  • 不會因緩衝區溢位或外部服務不可用而丟失資料
  • 立即寫入和存取

缺點：

  • 資料寫入主節點上的永續性儲存區(hostpath)
  • 日誌量龐大，只能保留短時間
  • 日誌分散在不同節點上，節點不可用或無法存取PV時可能丟失資料

替代方案（增強型日誌後端）

另一種解決方案是將資料寫入頻繁輪替的檔案系統（日誌後端），然後透過額外服務收集並傳送到外部服務（如OpenSearch）。這種方法透過在兩個位置同時儲存資料來最小化日誌存取失敗的可能性，同時減輕本地儲存和API伺服器的負載。

以下是使用Fluentbit Operator或Vector收集日誌的實際案例。這些工具可以將日誌重定向到不同的分析服務。

透過一次性設定日誌收集器，我們可以獲得一個穩定的系統，結合了兩種日誌記錄和儲存方法的優點。在這個系統中，可以收集不同級別的日誌和事件，並在一個地方進行研究。例如，可以使用單一日誌收集器收集kubernetes事件、Kyverno事件以及其他K8s事件。將日誌收集器放置在Kubernetes環境中還可以解決解決方案擴充套件的問題。

優點：

  • 方便存取所有主節點的所有日誌
  • 可以同時在叢集內部和外部儲存中檢視日誌
  • 無需過載本地儲存即可長期儲存日誌
  • 避免透過外部API伺服器傳輸時的資料丟失

缺點：

  • 外部服務如Fluentbit Operator常含高危漏洞：CVE-2024-26461、CVE-2023-2953等
  • 在嘗試確保解決方案安全時，不應引入額外威脅
  • 需要優秀的安全工作者或供應商的現成解決方案

方法比較

特性日誌後端Webhook後端增強型日誌後端
設定複雜度低中/高中
需要額外服務否是是
日誌分析便利性中高高
可靠性高取決於附加服務高
可擴充套件性低高高
執行速度低取決於附加服務中

實作稽核日誌的最佳實踐

在我多年管理Kubernetes叢集的經驗中，玄貓發現實作稽核日誌時需要考慮幾個關鍵因素：

  1. 安全需求評估：首先評估組織的安全合規要求，確定需要記錄哪些操作和存取
  2. 資源考量：評估叢集資源，確保日誌儲存不會影響生產工作負載
  3. 保留策略：根據合規要求和資源限制，制定合適的日誌保留政策
  4. 自動化監控：設定自動化監控，及時發現稽核日誌系統的問題

對於大多數生產環境，我建議採用增強型日誌後端方案，結合本地暫存和外部長期儲存的優點，同時確保安全性和可靠性。

選擇合適的日誌收集目標系統

在多年的 Kubernetes 安全稽核工作中，玄貓發現選擇適當的日誌收集與分析工具至關重要。對於需要深度分析 Kubernetes 稽核日誌的團隊，SIEM 系統無疑是功能最完整的選擇。由於 Kubernetes 稽核日誌通常以字串或 JSON 格式輸出，與 SIEM 系統整合相對直接，與大多數 SIEM 平台還提供強大的過濾功能，有效減少不必要的日誌體積。

然而，我特別想在此推薦 ELK 系列中的 OpenSearch，這個工具與 Kubernetes Audit Policy 一樣被許多團隊低估了。從我多年的實務經驗來看，OpenSearch 可能是許多組織的理想選擇，原因如下：

  1. 不需要昂貴的系統投資
  2. 佈署與設定相對簡單
  3. 同時適用於叢集管理員和資安團隊

近期 OpenSearch 在日誌分析領域取得了顯著進步，現在已經能夠分析日誌並識別異常，同時在觸發條件滿足時傳送警示通知。

在 OpenSearch 的通知（Notification）區段，你可以選擇多種資料接收管道，包括 Webhook、Slack、電子郵件等。而在警示（Alerting）設定中，你能夠建立監控器來追蹤特定索引中的觸發條件，並將事件傳送到指定管道。

此外，OpenSearch Operator 允許透過 SSO 與叢集建立連線，並傳遞使用者資訊，同時保留相應角色資料以保護敏感資訊。

OpenSearch 中 Kube-Audit 日誌索引的容量規劃

假設我們已經將日誌傳送到 OpenSearch，建立了 kube-audit-myclustername 索引，並設定了索引模式以存取所有叢集主節點的稽核日誌。然而，這才是工作的開始，而非結束。

根據你設定的稽核政策和需要記錄的資料，你會產生大量需要儲存的記錄。以記錄節點、工作負載、Secret、ConfigMap 和網路政策等基本資料的政策為例，在一個有 350 個 Pod 的活躍生產叢集中，每天會產生約 4GB 的日誌。

如果記憶體容量不足，日誌將無法在 OpenSearch 中正常存取。為解決這個問題，必須設定日誌輪替政策。

索引保留時間越長，佔用的磁碟空間就越大。若要對現有索引套用政策，請前往 Index Management。新建立的索引將自動套用這些政策。

特殊考量事項

服務帳號資料的記錄

所有日誌記錄可以根據操作者大致分為三類別：

  • 由使用者執行
  • 由服務帳號執行
  • 未確定身分（匿名）

未確定身分的記錄可能來自未授權的請求，或是 Kubernetes 自身對 API 伺服器進行的健康檢查。

使用者操作的記錄相對直觀。然而，Kube-Audit 日誌中的大部分記錄實際上來自服務帳號。這時需要權衡資料量與安全性。稽核政策無法僅根據群組篩選所有服務帳號記錄，因為除了 service-accounts 群組外，還有 system:authenticated 群組。在這種情況下，有幾種可能的解決方案：

  1. 不排除服務帳號記錄：OpenSearch、SIEM 等工具可以定義每個服務帳號的預期行為模式，並偵測異常，這有助於快速回應安全事件
  2. 實作控制器：自動捕捉新建立的服務帳號，並按排程（如每日一次）將其加入稽核政策，但需注意資料遺失風險和 Kube-API 伺服器重啟需求
  3. 混合策略：不記錄系統服務的服務帳號請求，但記錄所有自訂服務帳號的操作

佈署與修改注意事項

  • Audit Policy 對錯誤毫不寬容：例如，若從 NotePad++ 複製設定時，看似完美的設定可能包含空格轉換成的製表符，導致 Kube-API 伺服器當機
  • 佈署政策需要重新啟動 Kube-API 伺服器

重啟可以在修改 Kube-API 伺服器引數時進行，或透過控制器自動執行，該控制器會監控變更、驗證政策檔案並重新啟動 Kube-API 伺服器。

物件修改的記錄

如果叢集中有在啟動前修改物件的服務，修改資訊可能會記錄在日誌中。例如，來自 Kyverno 的 Mutation Webhook 會記錄為註解：

annotations.mutation.webhook.admission.k8s.io/round_0_index_3
{"configuration":"kyverno-verify-mutating-webhook-cfg","webhook":"monitor-
webhooks.kyverno.svc","mutated":true}

資料轉送過程中的損失風險

某些 Kubernetes 系統欄位（巢狀物件）在轉送到 OpenSearch 時會破壞記錄。可以透過日誌收集器的篩選器在傳送前移除這些欄位，確保所有資料正確接收。

Node/proxy 不會被記錄

直接在節點上執行的請求不會記錄在稽核日誌中，這可能導致惡意事件無法被察覺。為降低未知使用者透過 node/proxy 發出請求的風險，我建議：

  • 設定嚴格的角色存取政策（ClusterRoles）和使用者存取定義政策（如 OPA），最小化擁有 node/proxy 許可權的使用者數量
  • 在網路層面隔離叢集，限制直接連線節點的可能性
  • 在叢集中使用證書（如 ACME 或 Vault）降低資料存取風險

使用者認證不會被記錄

在實際環境中，我注意到使用者認證過程通常不會被記錄在稽核日誌中。這是因為認證過程由 Kubernetes API 伺服器處理，但發生在稽核日誌記錄之前。這一點在實作安全監控時需特別注意。

實用的 OpenSearch 日誌分析技巧

在多個客戶實作經驗中，我發現以下 OpenSearch 技巧特別有用：

建立自訂儀錶板

為了快速掌握叢集安全狀況，我通常會建立包含以下視覺化元素的儀錶板：

  1. 按操作類別分類別的請求數量趨勢圖
  2. 最活躍的服務帳號和使用者排行
  3. 拒絕請求的熱點圖，按時間和資源類別分析
  4. 敏感操作（如 Secret 存取、許可權變更）的即時監控

設定有效的警示

在 OpenSearch 中，我通常設定以下關鍵警示：

  1. 未授權存取嘗試激增
  2. 敏感資源（如 Secret）的異常存取模式
  3. 特權提升操作
  4. 服務帳號的非常規行為

最佳化索引策略

為了平衡效能和儲存需求，我採用的索引策略包括：

  1. 按時間範圍自動建立新索引（如每週或每月）
  2. 對較舊索引實施壓縮
  3. 根據安全需求和合規要求設定保留期
  4. 對重要事件建立單獨的長期儲存策略

我發現有效的日誌分析策略需要同時考慮技術實作和操作流程。OpenSearch 提供了一個強大與經濟的平台來處理 Kubernetes 稽核日誌，特別適閤中小型組織和初期實施。

在實施 Kubernetes 稽核日誌收集時，關鍵是找到安全監控需求與系統資源消耗之間的平衡點。過度記錄會導致儲存問題和分析效率降低，而記錄不足則可能錯過關鍵安全事件。

最後，稽核日誌只是整體 Kubernetes 安全策略的一部分。它應該與網路政策、RBAC 設定、執行時安全和定期安全審查等措施結合使用，才能提供全面的安全防護。透過結合這些方法，你的團隊將能夠建立一個既安全又高效的 Kubernetes 環境。

稽核日誌真實性：Kubernetes 稽核日誌的可靠性與偽造風險

稽核日誌的可信度問題

在 Kubernetes 環境中，稽核日誌（Audit Logs）是系統安全性和合規性的重要組成部分，然而這些日誌的可靠性存在一定風險。玄貓在多年的 Kubernetes 安全稽核經驗中發現，攻擊者可以透過特定技術偽造稽核日誌中的重要資訊，特別是 SourceIP 和 auditID 欄位，這對安全監控帶來挑戰。

HTTP 標頭注入與日誌偽造

攻擊者可以透過在 API 請求中增加特定 HTTP 標頭來偽造日誌資訊。這種技術特別危險，因為它允許惡意使用者在不改變實際行為的情況下，讓自己的活動看起來像是來自合法服務。

常見的可被用於偽造的 HTTP 標頭包括：

  • X-Forwarded-For：可用於偽造來源 IP 地址
  • X-Real-IP：同樣可用於修改請求的來源 IP
  • Audit-ID：可直接指定稽核 ID，混淆追蹤

指定自訂 Audit-ID 的實際案例

當攻擊者執行以下命令時：

curl -H 'Audit-ID: Lorem' http://127.0.0.1:8001/api/v1/pods/

系統會生成包含自訂 auditID 的稽核日誌：

{
  "kind": "Event",
  "apiVersion": "audit.k8s.io/v1",
  "level": "Metadata",
  "auditID": "Lorem",
  "stage": "RequestReceived",
  "requestURI": "/api/v1/pods/",
  "verb": "list",
  "user": {
    "username": "kubernetes-admin",
    "groups": ["system:masters", "system:authenticated"]
  },
  "sourceIPs": ["127.0.0.1", "172.18.0.1"],
  "userAgent": "curl/7.81.0",
  "objectRef": {
    "resource": "pods",
    "apiVersion": "v1"
  },
  "requestReceivedTimestamp": "2023-10-01T09:25:13.742237Z",
  "stageTimestamp": "2023-10-01T09:25:13.742237Z"
}

IP 地址偽造示範

攻擊者也可以同時偽造來源 IP 地址：

curl -H 'Audit-ID: Lorem' -H 'X-Forwarded-For: 8.8.8.8' http://127.0.0.1:8001/api/v1/pods/

這會在稽核日誌中顯示偽造的 IP 地址：

{
  "kind": "Event",
  "apiVersion": "audit.k8s.io/v1",
  "level": "Metadata",
  "auditID": "Lorem",
  "stage": "ResponseComplete",
  "requestURI": "/api/v1/pods/",
  "verb": "list",
  "user": {
    "username": "kubernetes-admin",
    "groups": ["system:masters", "system:authenticated"]
  },
  "sourceIPs": ["8.8.8.8", "127.0.0.1", "172.18.0.1"],
  "userAgent": "curl/7.81.0",
  "objectRef": {
    "resource": "pods",
    "apiVersion": "v1"
  },
  "responseStatus": {
    "metadata": {},
    "code": 200
  },
  "requestReceivedTimestamp": "2023-10-01T09:28:15.307641Z",
  "stageTimestamp": "2023-10-01T09:28:15.313353Z",
  "annotations": {
    "authorization.k8s.io/decision": "allow",
    "authorization.k8s.io/reason": ""
  }
}

如何檢測稽核日誌偽造

要有效應對稽核日誌偽造的風險，玄貓建議實施以下安全措施：

  1. 行為異常偵測：建立服務帳號和使用者的基準行為模型，並監控偏離這些模型的異常活動
  2. IP 地址驗證：實施多層驗證機制，不僅依賴單一來源 IP 資訊
  3. API 伺服器設定強化：考慮限制對 Kubernetes API 的 HTTP 標頭修改能力
  4. 日誌關聯分析：將稽核日誌與其他系統日誌進行交叉驗證，識別不一致之處

在玄貓處理的一次安全事件中，透過比對網路流量日誌和 Kubernetes 稽核日誌，成功識別出一個攻擊者透過偽造 IP 地址來掩蓋其活動的嘗試。這種多源日誌關聯分析對於提高安全監控的有效性至關重要。

Kubernetes 稽核日誌的價值與總結

儘管存在可偽造性的風險，Kubernetes 稽核日誌仍然是安全監控和事件調查的重要工具。玄貓認為，理解其侷限性並實施適當的緩解措施，才能最大化其安全價值。

Kubernetes 稽核日誌系統提供了多方面的優勢：

  • 提供成功和失敗操作的詳細記錄，支援多種詳細程度級別
  • 透過 YAML 清單實作彈性設定
  • JSON 格式輸出便於與各種日誌分析系統整合
  • 為安全工作者、開發人員和系統分析師提供寶貴的可見性

在現代雲原生環境中，稽核日誌是實作透明度和安全性的關鍵元素。透過瞭解其可能的弱點並實施適當的監控策略，組織可以有效地利用稽核日誌來增強其 Kubernetes 環境的安全態勢。

玄貓

玄貓

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