本頁面提供 Google Kubernetes Engine (GKE) 稽核記錄政策的總覽。本頁面說明 GKE 如何擷取及記錄叢集中的事件、影響記錄資訊的因素、資訊的儲存位置,以及影響稽核記錄顯示內容的政策。
如需啟用及查看不同類型稽核記錄的操作說明,以及必要的身分與存取權管理權限,請參閱 GKE 稽核記錄資訊。
本頁面適用於安全性專家,可協助您深入瞭解叢集中發生的活動,以便監控安全威脅、追蹤變更及排解問題。如要進一步瞭解 Google Cloud 內容中提及的常見角色和範例工作,請參閱常見的 GKE Enterprise 使用者角色和工作。
閱讀本頁內容前,請先熟悉下列主題:
稽核政策總覽
在 GKE 叢集中,Kubernetes API 伺服器會將稽核記錄項目寫入 GKE 代管的後端。GKE 接收 Kubernetes API 伺服器的記錄項目時,會將記錄項目寫入專案的管理員活動記錄和資料存取記錄。
有兩個政策會影響您在專案稽核記錄裡看到的內容:
Kubernetes 稽核政策,用以定義事件記錄為記錄項目時應遵循的規則。此外,此政策也指定應該納入記錄項目之中的資料。
GKE 稽核政策會決定哪些項目要寫入管理員活動記錄,哪些項目要寫入資料存取記錄。
寫入資料存取記錄的稽核記錄取決於稽核記錄設定。資料存取記錄採用 Google Cloud Observability 定價。管理員活動記錄不收費。GKE 支援下列類型的資料存取記錄。
ADMIN_READ
:讀取 Kubernetes 資源中繼資料的作業,例如列出 Pod。DATA_READ
:在 Kubernetes 資源中讀取資料的作業,例如讀取 Pod 的記錄。DATA_WRITE
:將資料寫入 Kubernetes 資源的作業,例如更新 Pod 狀態。
詳情請參閱「設定資料存取稽核記錄」。
Kubernetes 稽核政策
Kubernetes API 伺服器遵循 kube-apiserver 指令中 --audit-policy-file
標記指定的政策。
GKE 啟動 Kubernetes API 伺服器時,會設定 --audit-policy-file
標記的值,藉此提供稽核政策檔案。在開放原始碼 Kubernetes 存放區中,您可以看到 configure-helper.sh 指令碼,其中會產生稽核政策檔案。只要直接查看指令碼,就能看到稽核政策檔案大部分的內容。
事件和階段
某個人或某個元件向 Kubernetes API 伺服器提出要求時,該要求會經過一或多個「階段」:
階段 | 說明 |
---|---|
RequestReceived (要求已收到) | 稽核處理常式已收到要求。 |
ResponseStarted (回應已開始) | 回應標頭已傳送,但回應內文尚未傳送。 |
ResponseComplete (回應已完成) | 回應內文已完成,不會再送出更多位元組。 |
Panic (錯誤) | 發生內部伺服器錯誤,該要求未完成。 |
各個要求階段分別會產生一個「事件」,而事件會根據政策進行處理。政策會指定事件是否應記錄為記錄項目,如果答案為是,那麼政策也會指定哪些資料應納入記錄項目之中。
稽核層級
Kubernetes 稽核政策檔案含有規則清單。在政策檔案中,第一條符合事件的規則會設定事件的「稽核層級」。
規則可指定以下其中一個稽核層級:
層級 | 說明 |
---|---|
None (無) | 不替事件建立記錄項目。 |
Metadata (中繼資料) | 建立記錄項目。將中繼資料納入,但不納入要求內文或回應內文。 |
Request (要求) | 建立記錄項目。將中繼資料與要求內文納入,但不納入回應內文。 |
RequestResponse (要求回應) | 建立記錄項目。將中繼資料、要求內文和回應內文全數納入。 |
以下為規則範例。如果事件符合規則,Kubernetes API 伺服器就會建立 Request
層級的記錄項目。
- level: Request userGroups: ["system:nodes"] verbs: ["update","patch"] resources: - group: "" # core resources: ["nodes/status", "pods/status"] omitStages: - "RequestReceived"
如果符合下列所有條件,就表示事件與規則相符:
- 該事件不符合政策檔案裡任何一條先前的規則。
- 進行呼叫的身分在
system:nodes
使用者群組裡。 - 該呼叫是
update
要求或patch
要求。 - 該要求跟
nodes/status
資源或pods/status
資源有關。 - 該事件不適用呼叫的
RequestReceived
階段。
GKE 稽核政策
GKE 接收 Kubernetes API 伺服器傳來的記錄項目時,就會套用自己的政策,以判定哪些項目要寫入到專案的管理員活動記錄、哪些項目要寫入到專案的資料存取記錄。
在大多數情況下,GKE 會將下列規則套用到 Kubernetes API 伺服器傳來的記錄項目:
凡是代表
create
、delete
和update
要求的項目都會移到管理員活動記錄。凡代表
get
、list
和updateStatus
要求的項目,一律屬於資料存取記錄。
有關定價和預設啟用記錄類型的詳情,請參閱記錄詳細資料。
GKE 叢集的 Kubernetes 稽核政策檔案
對於 GKE 叢集,Kubernetes 稽核政策檔案會從以下規則開始:指定某些事件應該完全不要記錄的規則。例如,此規則表明 kubelet
提出的 get
要求只要跟 nodes
資源或 nodes/status
資源有關,都不應記錄。回想一下,None
層級就表示任何相符的事件都不應記錄:
- level: None users: ["kubelet"] # legacy kubelet identity verbs: ["get"] resources: - group: "" # core resources: ["nodes", "nodes/status"]
在 level: None
規則清單之後,政策檔案還有特殊案例的規則清單。例如,以下這條特殊案例規則就規定某些要求必須記錄在 Metadata
層級:
- level: Metadata resources: - group: "" # core resources: ["secrets", "configmaps"] - group: authentication.k8s.io resources: ["tokenreviews"] omitStages: - "RequestReceived"
如果符合下列所有條件,就表示事件與規則相符:
- 該事件不符合政策檔案裡任何一條先前的規則。
- 該要求與
secrets
、configmaps
或tokenreviews
資源類型有關。 - 該事件不適用呼叫的
RequestReceived
階段。
在特殊案例規則清單之後,政策檔案還有一些通則。
如要查看指令碼中的通則,就必須以 known_apis
的值取代 ${known_apis}
。取代後就會獲得這樣的規則:
- level: Request verbs: ["get", "list", "watch"] resources: - group: "" # core - group: "admissionregistration.k8s.io" - group: "apiextensions.k8s.io" - group: "apiregistration.k8s.io" - group: "apps" - group: "authentication.k8s.io" - group: "authorization.k8s.io" - group: "autoscaling" - group: "batch" - group: "certificates.k8s.io" - group: "extensions" - group: "metrics.k8s.io" - group: "networking.k8s.io" - group: "policy" - group: "rbac.authorization.k8s.io" - group: "settings.k8s.io" - group: "storage.k8s.io" omitStages: - "RequestReceived"
該規則適用於以下事件:不符合政策檔案裡任何一條先前規則,且不在 RequestReceived
階段的事件。該規則表明 get
、list
和 watch
要求如果是跟其中一個列出群組裡的資源有關,都應記錄在 Request
層級。
政策檔案裡的下一條規則如下所示:
- level: RequestResponse resources: - group: "" # core - group: "admissionregistration.k8s.io" - group: "apiextensions.k8s.io" - group: "apiregistration.k8s.io" - group: "apps" - group: "authentication.k8s.io" - group: "authorization.k8s.io" - group: "autoscaling" - group: "batch" - group: "certificates.k8s.io" - group: "extensions" - group: "metrics.k8s.io" - group: "networking.k8s.io" - group: "policy" - group: "rbac.authorization.k8s.io" - group: "settings.k8s.io" - group: "storage.k8s.io" omitStages: - "RequestReceived"
該規則適用於以下事件:不符合政策檔案裡任何一條先前規則,且不在 RequestReceived
階段的事件。要特別注意的是,該規則不適用於以下的讀取要求:get
、list
和 watch
,但卻適用於 create
、update
和 delete
這三種寫入要求。該規則表明寫入要求應記錄在 RequestResponse
層級。
GKE 叢集的 Kubernetes 稽核政策摘要
以下列出 GKE 叢集的 Kubernetes 稽核政策摘要:
一般來說,
create
、update
和delete
等寫入要求會記錄在RequestResponse
層級。一般來說,
get
、list
和watch
這三種事件會記錄在Metadata
層級。有些事件會被視為特殊案例。如需特殊案例的最終要求清單,請參閱政策指令碼。特殊案例包括:
kubelet
、system:node-problem-detector
或system:serviceaccount:kube-system:node-problem-detector
提出的nodes/status
資源或pods/status
資源更新要求和修補要求,一律記錄在「Request」(要求) 層級。system:nodes
群組中任何身分對nodes/status
資源或pods/status
資源提出的更新和修補要求,一律記錄在「Request」(要求) 層級。system:serviceaccount:kube-system:namespace-controller
提出的deletecollection
要求,一律記錄在「Request」(要求) 層級。secrets
資源、configmaps
資源或tokenreviews
資源的要求,一律記錄在「Metadata」(中繼資料) 層級。
某些要求完全不會記錄下來。如需未記錄的要求清單,請參閱政策指令碼中的
level: None
規則。系統不會記錄下列要求:system:kube-proxy
提出的要求,用以查看endpoints
資源、services
資源或services/status
資源。system:unsecured
對kube-system
命名空間中的configmaps
資源提出的取得要求。kubelet
對nodes
資源或nodes/status
資源提出的取得要求。system:nodes
群組中任何身分對nodes
資源或nodes/status
資源提出的取得要求。system:kube-controller-manager
、system:kube-scheduler
或system:serviceaccount:endpoint-controller
對kube-system
命名空間endpoints
資源提出的取得及更新要求。system:apiserver
對namespaces
資源、namespaces/status
資源或namespaces/finalize
資源提出的取得要求。system:kube-controller-manager
對metrics.k8s.io
群組中任何資源提出的取得及列出要求。對符合
/healthz*
、/version
或/swagger*
的網址提出要求。