最全 Kubernetes 審計日誌方案

1. 當前/歷史上叢集發生了哪些變更事件；

2. 這些變更操作者是誰，是系統元件還是使用者，是哪個系統元件/使用者；

3. 重要變更事件的詳細內容是什麼，比如修改了 POD 中的哪個引數；

4. 事件的結果是什麼，成功還是失敗；

5. 操作使用者來自哪裡，叢集內還是叢集外。

K8s 中的審計日誌是標準的 JSON 格式，APIServer 會根據具體的日誌策略將對應的審計日誌儲存本地，並可以設定最大儲存週期、時間、輪轉策略等。

關於審計日誌格式和策略的詳細介紹，可以參考Audit官方文件（https://kubernetes.io/docs/tasks/debug-application-cluster/audit/）。

日誌記錄階段

審計日誌根據日誌策略可以選擇在事件執行的某個階段記錄，目前支援的事件階段有：

• RequestReceived - 接收到事件且在分配給對應 handler 前記錄;

• ResponseStarted - 開始響應資料的 Header 但在響應資料 Body 傳送前記錄，這種一般應用在持續很長的操作事件，例如 watch 操作;

• ResponseComplete - 事件響應完畢後記錄;

• Panic - 內部出現 panic 時記錄。

日誌記錄等級

審計日誌根據日誌策略可以選擇事件儲存的等級，根據等級不同，APIServer 記錄日誌的詳細程度也不同。目前支援的事件等級有：

• None - 不記錄日誌;

• Metadata - 只記錄 Request 的一些 metadata (例如 user, timestamp, resource, verb 等)，但不記錄 Request 或 Response 的 body;

• Request - 記錄 Request 的 metadata 和 body;

• RequestResponse - 最全記錄方式，會記錄所有的 metadata、Request 和 Response 的 body。

日誌記錄策略

APIServer 支援對每類不同的資源設定不同的審計日誌策略，包括日誌記錄階段以及日誌記錄等級，目前官方以及很多雲廠商都會提供日誌策略，一般都遵循以下原則：

• 在收到請求後不立即記錄日誌，當返回體 header 傳送後才開始記錄;

• 對於大量冗餘的 kube-proxy watch 請求，kubelet 和 system:nodes 對於 node 的 get 請求，kube 元件在 kube-system 下對於 endpoint 的操作，以及 apiserver 對於 namespaces 的 get 請求等不作審計;

• 對於/healthz_，/version_, /swagger*等只讀 url 不作審計;

• 對於可能包含敏感資訊或二進位制檔案的 secrets，configmaps，tokenreviews 介面的日誌等級設為 metadata，該 level 只記錄請求事件的使用者、時間戳、請求資源和動作，而不包含請求體和返回體;

• 對於一些如 authenticatioin、rbac、certificates、autoscaling、storage 等敏感介面，根據讀寫記錄相應的請求體和返回體。

審計日誌分析現狀

目前,對於 K8s 上的 APIServer 審計日誌地支援，大部分廠商還停留在策略設定或日誌採集的階段，最多隻支援將資料採集到日誌中心，配合索引進行關鍵詞查詢。

下圖是一個 Level 為 Metadata 的審計日誌記錄，各類欄位有 20 多個，如果是 Level 為 Request 或 RequestResponse 的日誌欄位會更多，可能達到上百個。要實現審計日誌分析，必須理解這些欄位的含義，此外還需理解每個欄位的取值範圍以及每種取值對應的含義，學習代價非常之大。

{
  "kind": "Event",
  "apiVersion": "audit.k8s.io/v1beta1",
  "metadata": {
    "creationTimestamp": "2019-01-14T07:48:38Z"
  },
  "level": "Metadata",
  "timestamp": "2019-01-14T07:48:38Z",
  "auditID": "cf2915c0-0b43-4e1d-9d66-fbae481a0e0a",
  "stage": "ResponseComplete",
  "requestURI": "/apis/authentication.k8s.io/v1beta1?timeout=32s",
  "verb": "get",
  "user": {
    "username": "system:serviceaccount:kube-system:generic-garbage-collector",
    "uid": "cd3fbe04-0508-11e9-965f-00163e0c7cbe",
    "groups": [
      "system:serviceaccounts",
      "system:serviceaccounts:kube-system",
      "system:authenticated"
    ]
  },
  "sourceIPs": [
    "192.168.0.249"
  ],
  "responseStatus": {
    "metadata": {},
    "code": 200
  },
  "requestReceivedTimestamp": "2019-01-14T07:48:38.214979Z",
  "stageTimestamp": "2019-01-14T07:48:38.215102Z",
  "annotations": {
    "authorization.k8s.io/decision": "allow",
    "authorization.k8s.io/reason": "RBAC: allowed by ClusterRoleBinding \"system:discovery\" of ClusterRole \"system:discovery\" to Group \"system:authenticated\""
  }
}

阿里雲 Kubernetes 審計日誌方案

為儘可能減少使用者對於審計日誌的分析代價，阿里雲容器服務將 Kubernetes 審計日誌與日誌服務 SLS 打通，推出了一站式的 Kubernetes 審計日誌方案，讓每個使用者都能夠以圖形化報表的方式進行叢集的審計分析。

1. 為儘可能保證叢集安全性，阿里雲容器服務 Kubernetes 預設為使用者開啟了 APIServer 審計日誌並設定了較為安全且通用的審計日誌策略，所有（符合審計策略）使用者、元件對 APIServer 的訪問都會被記錄下來；

2. Kubernetes 叢集中預置的日誌元件 Logtail 會將 APIServer 的審計日誌自動採集到阿里雲日誌服務；

3. 日誌服務預設會為 APIServer 的審計日誌建立索引、報表等；

4. 容器服務控制檯已經和日誌服務打通，叢集管理員可以直接在控制檯上檢視審計日誌的各項報表以及指標；

5. 若叢集管理員還有設定告警、自定義分析等需求，可直接登入日誌服務控制檯進行操作。

得益於阿里雲日誌服務的強大功能，該方案不僅大大降低了 K8s 審計日誌分析的門檻，從分析能力、視覺化、互動方式、效能等各方面都具有很強的優勢：

審計日誌方案概覽

審計報表

我們預設為 Kubernetes 叢集建立了 3 個報表，分別是審計中心概覽、資源操作概覽和資源詳細操作列表：

1. 審計中心概覽展示 Kubernetes 叢集中的事件整體概覽資訊以及重要事件（公網訪問、命令執行、刪除資源、訪問保密字典等）的詳細資訊;

2. 資源操作概覽展示 Kubernetes 叢集中常見的計算資源、網路資源以及儲存資源的操作統計資訊，操作包括建立、更新、刪除、訪問。其中

3. 計算資源包括：Deployment、StatefulSet、CronJob、DaemonSet、Job、Pod；

4. 網路資源包括：Service、Ingress；

5. 儲存資源包括：ConfigMap、Secret、PersistentVolumeClaim。

6. 資源詳細操作列表用於展示 Kubernetes 叢集中某類資源的詳細操作列表，通過選擇或輸入指定的資源型別進行實時查詢，該表報會顯示：資源操作各類事件的總數、namespace 分佈、成功率、時序趨勢以及詳細操作列表等。

所有的報表均支援設定時間範圍、子賬號 ID、Namespace 等進行自定義過濾並實時重新整理，通過這些報表，叢集管理員只用點選滑鼠就可以獲取到：

1. 最近任一時間段內建立/刪除/修改了哪些資源；

2. 事件的時序趨勢如何；

3. 具體是哪個子賬號操作了資源；

4. 操作的 IP 源是否為公網、地域分佈如何、來源 IP 是否高危；

5. 具體操作的事件 ID、時間、結果、涉及的資源等詳細日誌；

6. 哪個子賬號登入了容器或訪問了保密字典…