最全Kubernetes審計日誌方案

前言

當前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的日誌字段會更多，可能達到上百個。要實現審計日誌分析，必須理解這些字段的含義，此外還需理解每一個字段的取值範圍以及每種取值對應的含義，學習代價很是之大。

{
  "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集羣中常見的計算資源、網絡資源以及存儲資源的操做統計信息，操做包括建立、更新、刪除、訪問。其中

   1. 計算資源包括：Deployment、StatefulSet、CronJob、DaemonSet、Job、Pod；
   2. 網絡資源包括：Service、Ingress；
   3. 存儲資源包括：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版

 

原文連接 更多技術乾貨 請關注阿里云云棲社區微信號 ：yunqiinsight