稽核

Kubernetes *稽核* 提供一組與安全性相關且依時間順序排列的記錄，記錄叢集中動作的順序。叢集會稽核使用者、使用 Kubernetes API 的應用程式以及控制平面本身產生的活動。

稽核讓叢集管理員能夠回答下列問題

發生了什麼事？
何時發生的？
誰發起的？
在什麼上發生的？
在哪裡觀察到的？
從哪裡發起的？
要往哪裡去？

稽核記錄在 kube-apiserver 元件內部開始其生命週期。每個執行階段的每個請求都會產生一個稽核事件，然後根據特定政策進行預先處理，並寫入後端。該政策決定了記錄的內容，而後端則持久化記錄。目前的後端實作包括日誌檔案和 Webhook。

每個請求都可以與相關的 *階段* 一起記錄。定義的階段為

RequestReceived - 為事件產生的階段，一旦稽核處理常式收到請求，並且在將其委派到處理常式鏈之前。
ResponseStarted - 一旦發送回應標頭，但在發送回應本文之前。此階段僅針對長時間運行的請求（例如 watch）產生。
ResponseComplete - 回應本文已完成，並且不會再發送任何位元組。
Panic - 當發生 panic 時產生的事件。

注意

稽核事件組態的組態與事件 API 物件不同。

稽核日誌記錄功能增加了 API 伺服器的記憶體消耗，因為每個請求都會儲存一些稽核所需的上下文。記憶體消耗取決於稽核日誌記錄組態。

稽核政策

稽核政策定義了關於應記錄哪些事件以及它們應包含哪些資料的規則。稽核政策物件結構在 audit.k8s.io API 群組中定義。當事件被處理時，它會與規則列表依序比較。第一個匹配的規則設定事件的 *稽核等級*。定義的稽核等級為

None - 不要記錄符合此規則的事件。
Metadata - 記錄包含元資料（請求使用者、時間戳記、資源、動詞等），但不包含請求或回應本文的事件。
Request - 記錄包含請求元資料和本文，但不包含回應本文的事件。這不適用於非資源請求。
RequestResponse - 記錄包含請求元資料、請求本文和回應本文的事件。這不適用於非資源請求。

您可以使用 --audit-policy-file 標誌將包含政策的檔案傳遞給 kube-apiserver。如果省略該標誌，則不會記錄任何事件。請注意，rules 欄位**必須**在稽核政策檔案中提供。沒有 (0) 條規則的政策被視為非法。

以下是一個稽核政策檔案範例

audit/audit-policy.yaml

apiVersion: audit.k8s.io/v1 # This is required.
kind: Policy
# Don't generate audit events for all requests in RequestReceived stage.
omitStages:
  - "RequestReceived"
rules:
  # Log pod changes at RequestResponse level
  - level: RequestResponse
    resources:
    - group: ""
      # Resource "pods" doesn't match requests to any subresource of pods,
      # which is consistent with the RBAC policy.
      resources: ["pods"]
  # Log "pods/log", "pods/status" at Metadata level
  - level: Metadata
    resources:
    - group: ""
      resources: ["pods/log", "pods/status"]

  # Don't log requests to a configmap called "controller-leader"
  - level: None
    resources:
    - group: ""
      resources: ["configmaps"]
      resourceNames: ["controller-leader"]

  # Don't log watch requests by the "system:kube-proxy" on endpoints or services
  - level: None
    users: ["system:kube-proxy"]
    verbs: ["watch"]
    resources:
    - group: "" # core API group
      resources: ["endpoints", "services"]

  # Don't log authenticated requests to certain non-resource URL paths.
  - level: None
    userGroups: ["system:authenticated"]
    nonResourceURLs:
    - "/api*" # Wildcard matching.
    - "/version"

  # Log the request body of configmap changes in kube-system.
  - level: Request
    resources:
    - group: "" # core API group
      resources: ["configmaps"]
    # This rule only applies to resources in the "kube-system" namespace.
    # The empty string "" can be used to select non-namespaced resources.
    namespaces: ["kube-system"]

  # Log configmap and secret changes in all other namespaces at the Metadata level.
  - level: Metadata
    resources:
    - group: "" # core API group
      resources: ["secrets", "configmaps"]

  # Log all other resources in core and extensions at the Request level.
  - level: Request
    resources:
    - group: "" # core API group
    - group: "extensions" # Version of group should NOT be included.

  # A catch-all rule to log all other requests at the Metadata level.
  - level: Metadata
    # Long-running requests like watches that fall under this rule will not
    # generate an audit event in RequestReceived.
    omitStages:
      - "RequestReceived"

您可以使用最小的稽核政策檔案來記錄 Metadata 等級的所有請求

# Log all requests at the Metadata level.
apiVersion: audit.k8s.io/v1
kind: Policy
rules:
- level: Metadata

如果您正在製作自己的稽核設定檔，則可以使用 Google Container-Optimized OS 的稽核設定檔作為起點。您可以查看 configure-helper.sh 腳本，該腳本會產生稽核政策檔案。您可以直接查看腳本來查看大部分稽核政策檔案。

您也可以參考 Policy 組態參考，以取得有關已定義欄位的詳細資訊。

稽核後端

稽核後端將稽核事件持久化到外部儲存空間。kube-apiserver 開箱即用地提供了兩個後端

日誌後端，將事件寫入檔案系統
Webhook 後端，將事件發送到外部 HTTP API

在所有情況下，稽核事件都遵循 Kubernetes API 在 audit.k8s.io API 群組中定義的結構。

注意

在修補程式的情況下，請求本文是一個包含修補程式操作的 JSON 陣列，而不是包含適當 Kubernetes API 物件的 JSON 物件。例如，以下請求本文是對 /apis/batch/v1/namespaces/some-namespace/jobs/some-job-name 的有效修補程式請求

[
  {
    "op": "replace",
    "path": "/spec/parallelism",
    "value": 0
  },
  {
    "op": "remove",
    "path": "/spec/template/spec/containers/0/terminationMessagePolicy"
  }
]

日誌後端

日誌後端以 JSONlines 格式將稽核事件寫入檔案中。您可以使用以下 kube-apiserver 標誌來組態日誌稽核後端

--audit-log-path 指定日誌檔路徑，供日誌後端寫入稽核事件。未指定此標記將停用日誌後端。- 代表標準輸出
--audit-log-maxage 定義舊稽核日誌檔要保留的最大天數
--audit-log-maxbackup 定義要保留的最大稽核日誌檔數量
--audit-log-maxsize 定義稽核日誌檔在輪替之前，其大小上限（單位為 MB）

如果你的叢集控制平面以 Pod 方式執行 kube-apiserver，請記得將 hostPath 掛載到原則檔案和日誌檔案的位置，以便稽核記錄能持續保存。例如

  - --audit-policy-file=/etc/kubernetes/audit-policy.yaml
  - --audit-log-path=/var/log/kubernetes/audit/audit.log

然後掛載磁碟區

...
volumeMounts:
  - mountPath: /etc/kubernetes/audit-policy.yaml
    name: audit
    readOnly: true
  - mountPath: /var/log/kubernetes/audit/
    name: audit-log
    readOnly: false

最後設定 hostPath

...
volumes:
- name: audit
  hostPath:
    path: /etc/kubernetes/audit-policy.yaml
    type: File

- name: audit-log
  hostPath:
    path: /var/log/kubernetes/audit/
    type: DirectoryOrCreate

Webhook 後端

Webhook 稽核後端會將稽核事件傳送到遠端 Web API，該 API 應為 Kubernetes API 的一種形式，包含身分驗證方式。你可以使用下列 kube-apiserver 標記來設定 Webhook 稽核後端

--audit-webhook-config-file 指定具有 Webhook 設定的檔案路徑。Webhook 設定實際上是一種特殊的 kubeconfig。
--audit-webhook-initial-backoff 指定在第一次失敗請求後，重試之前要等待的時間量。後續請求將以指數退避方式重試。

Webhook 設定檔使用 kubeconfig 格式來指定服務的遠端位址和用於連線的憑證。

事件批次處理

日誌和 Webhook 後端都支援批次處理。以 Webhook 為例，以下是可用標記的清單。若要取得日誌後端的相同標記，請將標記名稱中的 webhook 替換為 log。預設情況下，webhook 中啟用批次處理，而 log 中停用。同樣地，預設情況下，webhook 中啟用節流，而 log 中停用。

--audit-webhook-mode 定義緩衝策略。以下選項之一：
- batch - 緩衝事件並以非同步方式成批處理它們。這是預設值。
- blocking - 在處理每個個別事件時封鎖 API 伺服器回應。
- blocking-strict - 與 blocking 相同，但是當在 RequestReceived 階段稽核記錄期間發生失敗時，對 kube-apiserver 的整個請求都會失敗。

以下標記僅在 batch 模式中使用

--audit-webhook-batch-buffer-size 定義批次處理之前要緩衝的事件數量。如果傳入事件的速率超出緩衝區，則事件會被丟棄。
--audit-webhook-batch-max-size 定義一個批次中的最大事件數量。
--audit-webhook-batch-max-wait 定義在無條件批次處理佇列中的事件之前，要等待的最長時間量。
--audit-webhook-batch-throttle-qps 定義每秒產生的最大平均批次數量。
--audit-webhook-batch-throttle-burst 定義如果先前允許的 QPS 未充分利用，則在同一時刻產生的最大批次數量。

參數調整

應設定參數以適應 API 伺服器上的負載。

例如，如果 kube-apiserver 每秒接收 100 個請求，並且每個請求僅在 ResponseStarted 和 ResponseComplete 階段進行稽核，則應考慮每秒產生約 200 個稽核事件。假設一個批次最多有 100 個事件，則應將節流等級設定為至少每秒 2 個查詢。假設後端最多需要 5 秒才能寫入事件，則應將緩衝區大小設定為最多可容納 5 秒的事件；也就是說：10 個批次，或 1000 個事件。

然而，在大多數情況下，預設參數應該足夠，你無需擔心手動設定它們。你可以查看 kube-apiserver 公開的以下 Prometheus 指標和日誌，以監控稽核子系統的狀態。

apiserver_audit_event_total 指標包含匯出的稽核事件總數。
apiserver_audit_error_total 指標包含由於匯出期間發生錯誤而丟棄的事件總數。

日誌條目截斷

日誌和 Webhook 後端都支援限制記錄事件的大小。例如，以下是日誌後端可用的標記清單

audit-log-truncate-enabled 是否啟用事件和批次截斷。
audit-log-truncate-max-batch-size 發送到基礎後端的批次大小上限（單位為位元組）。
audit-log-truncate-max-event-size 發送到基礎後端的稽核事件大小上限（單位為位元組）。

預設情況下，webhook 和 log 中都停用截斷，叢集管理員應設定 audit-log-truncate-enabled 或 audit-webhook-truncate-enabled 以啟用此功能。

下一步

瞭解 Mutating webhook auditing annotations。
透過閱讀稽核設定參考文件，進一步瞭解 Event 和 Policy 資源類型。

上次修改時間：2024 年 10 月 22 日凌晨 3:28 PST：Update audit.md (#46655) (ae153723dd)

稽核

注意