在 Kubernetes 中啟用 Audit Log

1. 什麼是 Kubernetes Audit?

Kubernetes Auditing 功能提供了與安全相關的、按時間順序排列的記錄集， 記錄每個使用者、使用 Kubernetes API 的應用程式以及控制面自身引發的活動（所有存取 kube-apiserver 服務的客戶端）。

Audit 功能使得 K8s 叢集管理員能夠回答以下問題：

• 發生了什麼事？
• 什麼時候發生的？
• 誰觸發的？
• 活動發生在哪一個（些）物件上？
• 在哪觀察到的？
• 它從哪觸發的？
• 活動的後續處理行為是什麼？

這對平台管理者來說十分重要，能夠回答一些在故障時候出現的問題。哪個用戶，從哪個 ip 上，發起了什麼請求。如刪除了一個命名空間，導致這個命名空間下的所有 pod 被回收，對故障進行複盤。

Kubernetes Audit 功能由 kube-apiserver 服務提供。每個請求在不同執行階段都會產生 Audit Events；這些 Audit Events 會根據特定 Policy 被預處理並寫入後端。Policy 決定要記錄的內容，目前的後端支援 logs 檔案和 webhook。

每個請求都可被記錄其相關的階段（stage）。已定義的階段有：

• RequestReceived - 此階段對應 kube-apiserver audit handler 接收到請求後，且在將請求向下傳遞給處理鏈之前，立即把產生的事件給記錄下來。
• ResponseStarted - 在回應訊息的頭部發送後，回應訊息體發送前產生的事件。 只有長時間運行的請求（例如 watch）才會產生這個階段。
• ResponseComplete - 當回應訊息體完成且沒有更多資料需要傳輸的時候。（白話來說就是 kube-apiserver 已經完全處理完了該客戶端 (client) 提交的請求，在這個階段把 audit log 給記錄下來。）
• Panic - 當 panic 發生時產生。

設定 K8s Audit logs 注意事項：

1. audit logs 功能會增加 API Server 的記憶體消耗量，因為 audit 所需的部分上下文資訊 (context) 會針對每個請求儲存起來。記憶體消耗量取決於 audit logs 的設定。
2. 開啟 K8s 原生 Audit 功能必須設定 Audit Stage 和 Audit backend 否則不會執行 Audit Filter 邏輯。
3. 根據 Audit Policy 設定檔中的 omitStages 的定義值，不設定 omitStages 的話預設 RequestReceived、ResponseStarted、ResponseComplete 這三個階段都會產生 audit events，在保留的 Audit Stage 產生 audit events 並輸出到對應後端。