前言

當前Kubernetes（K8S）已經成為事實上的容器編排標準，大家關注的重點也不再是最新發布的功能、穩定性提升等，正如Kubernetes項目創始人和維護者談到，Kubernetes已經不再是buzzword，當我們談起它的時候，變得越發的boring，它作為成熟項目已經走向了IT基礎設施的中臺，為適應更大規模的生產環境和更多場景的應用不斷延展迭代。

而現在我們更加專注於如何利用K8S平臺進行CICD、發佈管理、監控、日誌管理、安全、審計等等。本期我們將介紹如何利用K8S中的Audit事件日誌來對平臺進行安全監控和審計分析。

IT設施/系統是當今每個互聯網公司最為重要的資產之一，除了成本外，這裡承載了所有的用戶訪問，同時保存了非常多的用戶、訂單、交易、身份等敏感信息。因此每個公司都有必要確保IT設施/系統是可靠、安全、未洩漏的。其中必不可少的環節是審計，通過審計我們可以知道系統在任一時間段內發生的事件以及對應關聯的內外部人員、系統，在損失發生後能夠立即知道具體是誰、在哪個時間對系統做了什麼事，同時基於審計事件的實時分析和告警，能夠提前發現問題並及時止損。

Kubernetes審計日誌概覽

Kubernetes作為容器編排領域的領導者、未來PAAS平臺的標準基座，在IT領域有著舉足輕重的影響，因此審計功能也是Kubernetes比不可少的安全功能之一。

Kubernetes在1.7版本中發佈了審計（Audit）日誌功能，審計（Audit）提供了安全相關的時序操作記錄（包括時間、來源、操作結果、發起操作的用戶、操作的資源以及請求/響應的詳細信息等），通過審計日誌，我們能夠非常清晰的知道K8S集群到底發生了什麼事情，包括但不限於：

1. 當前/歷史上集群發生了哪些變更事件。
2. 這些變更操作者是誰，是系統組件還是用戶，是哪個系統組件/用戶。
3. 重要變更事件的詳細內容是什麼，比如修改了POD中的哪個參數。
4. 事件的結果是什麼，成功還是失敗。
5. 操作用戶來自哪裡，集群內還是集群外。

日誌格式與策略

K8S中的審計日誌是標準的JSON格式，APIServer會根據具體的日誌策略將對應的審計日誌保存本地，並可以設置最大保存週期、時間、輪轉策略等。關於審計日誌格式和策略的詳細介紹，可以參考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的日誌字段會更多，可能達到上百個。要實現審計日誌分析，必須理解這些字段的含義，此外還需理解每個字段的取值範圍以及每種取值對應的含義，學習代價非常之大。

<code>{  "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\""  }}/<code>

阿里雲Kubernetes審計日誌方案

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

1. 為儘可能保證集群安全性，阿里雲容器服務Kubernetes默認為用戶打開了APIServer審計日誌並設置了較為安全且通用的審計日誌策略，所有（符合審計策略）用戶、組件對APIServer的訪問都會被記錄下來；
2. Kubernetes集群中預置的日誌組件Logtail會將APIServer的審計日誌自動採集到阿里雲日誌服務；
3. 日誌服務默認會為APIServer的審計日誌創建索引、報表等；
4. 容器服務控制檯已經和日誌服務打通，集群管理員可以直接在控制檯上查看審計日誌的各項報表以及指標；
5. 若集群管理員還有設置告警、自定義分析等需求，可直接登錄日誌服務控制檯進行操作。

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

審計日誌方案概覽

審計報表

我們默認為Kubernetes集群創建了3個報表，分別是審計中心概覽、資源操作概覽和資源詳細操作列表：

1. 審計中心概覽展示Kubernetes集群中的事件整體概覽信息以及重要事件（公網訪問、命令執行、刪除資源、訪問保密字典等）的詳細信息。
2. 資源操作概覽展示Kubernetes集群中常見的計算資源、網絡資源以及存儲資源的操作統計信息，操作包括創建、更新、刪除、訪問。其中計算資源包括：Deployment、StatefulSet、CronJob、DaemonSet、Job、Pod；網絡資源包括：Service、Ingress；存儲資源包括：ConfigMap、Secret、PersistentVolumeClaim。
3. 資源詳細操作列表用於展示Kubernetes集群中某類資源的詳細操作列表，通過選擇或輸入指定的資源類型進行實時查詢，該表報會顯示：資源操作各類事件的總數、namespace分佈、成功率、時序趨勢以及詳細操作列表等。

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

1. 最近任一時間段內創建/刪除/修改了哪些資源；
2. 事件的時序趨勢如何；
3. 具體是哪個子賬號操作了資源；
4. 操作的IP源是否為公網、地域分佈如何、來源IP是否高危；
5. 具體操作的事件ID、時間、結果、涉及的資源等詳細日誌；
6. 哪個子賬號登錄了容器或訪問了保密字典...

這裡我們選擇一個圖標做詳細說明：上圖是Kubernetes資源操作列表，這個報表完全是交互式的，用戶可以指定一種資源（比如Deployment、Ingress、Secret等），表報會自動渲染出關於這個資源的所有操作，功能包括：

1. 左上角會顯示對這個資源操作的用戶數、涉及Namespace數、涉及方法數、請求成功率等概覽信息；
2. 每種不同操作（增、刪、改、查）的數量以及Namespace分佈，用來確定涉及的Namespace；
3. 各類操作的時序分佈（按小時），數量較多的點一般都是發佈或系統被攻擊的時間點；
4. 各類操作的詳細列表，包括：事件ID、操作事件、操作資源、操作結果、賬號、地址；
5. 圖表中所有的事件ID都可以點擊並跳轉到原始的日誌，查看具體和這個事件ID關聯的詳細日誌；
6. 圖表中所有的IP地址都可以點擊並跳轉到外部的IP查詢庫，查詢該IP對應的地理位置、運營商等信息；
7. 圖表還支持根據賬號、namespace、請求碼等過濾，比如對某個用戶進行審計時，可以過濾子賬號，只關心該用戶的操作。

自定義告警

例如需要對公網訪問設置告警策略：出現公網訪問時立即告警，則只需3步就可完成設置：

1. 在審計報表的公網訪問圖表中點擊右上角高級選項-新建告警
2. 填入告警名稱、事件、判斷條件
3. 填入告警通知方式以及通知內容

自定義分析

如果容器服務Kubernetes版提供的默認報表無法滿足您的分析需求，可以直接使用日誌服務SQL、儀表盤等功能進行自定義的分析和可視化。

嚐鮮

為了讓大家可以體驗Kubernetes審計日誌功能，我們特別開通了體驗中心，大家可以通過 https://promotion.aliyun.com/ntms/act/logdoclist.html 進入，該頁面提供了非常多和Kubernetes相關的報表。

參考文檔

1. kubernetes auditing
2. Kubernetes 的審計日誌和採集
3. 阿里雲容器服務Kubernetes審計日誌
4. 阿里雲日誌服務
5. 阿里雲容器服務Kubernetes版

閱讀更多 Echa攻城獅 的文章

關鍵字: 最全 日誌 用戶