背景概念

出於安全方面的考慮，Kubernetes提供了日誌審計記錄，用來記錄不同普通使用者、管理員和系統中各個元件的日誌資訊。

Kubernetes日誌審計是Kube-apiserver元件的一部分功能，通過日誌審計來記錄apiserver上面所有請求處理過程。每條審計日誌記錄包括兩行：

1、  請求行：唯一ID、源IP、請求使用者、請求資源資訊、模擬資訊等。

2、  響應行：唯一ID、相應資訊程式碼。

通過唯一ID就可以識別出對應的請求行和響應行。

下面的例子就是admin使用者查詢default名稱空間中pod資訊的兩行審計日誌資訊。

2017-03-21T03:57:09.106841886-04:00 AUDIT:id="c939d2a7-1c37-4ef1-b2f7-4ba9b1e43b53" ip="127.0.0.1"method="GET" user="admin"groups="\"system:masters\",\"system:authenticated\""as="<self>" asgroups="<lookup>"namespace="default" uri="/api/v1/namespaces/default/pods"
2017-03-21T03:57:09.108403639-04:00 AUDIT:id="c939d2a7-1c37-4ef1-b2f7-4ba9b1e43b53" response="200"
 

1.7新特性

我們先來看看1.7版本中日誌審計相關的幾個核心結構體：

在Kubernetes 1.7中，新增加了兩個結構體，分別是AuditOptions和AuditWebhookOptions。在AuditOptions結構體中通過LogOptions引數來對應之前版本的AuditLogOptions結構體。

一、AuditLogOptions結構體介紹

1、  Path引數：如果設定了這個引數，那麼所有訪問apiserver的請求都會被記錄到這個引數指向的檔案，也可以設定成“-”，這樣表示請求輸出到標準輸出中。

2、  MaxAge引數：儲存日誌審計記錄的最大天數，超出儲存最大天數的日誌審計記錄都會被刪除掉。

3、  MaxBackups引數：儲存日誌審計記錄檔案的最大個數，超出儲存最大個數的日誌審計記錄都會被刪除掉。

4、  MaxSize引數：一個日誌審計記錄檔案的最大空間，單位是M。

二、AuditWebhookOptions結構體介紹

1、  ConfigFile引數：將Kubernetes日誌審計結果向外部輸出的配置檔案。

2、  Mode引數：將Kubernetes日誌審計結果向外部輸出模式。在1.7版本中有兩種輸出模式，batch模式，表示快取日誌審計記錄，然後批量傳送給外部接收端；blocking模式，表示每條傳送給外部接收端，傳送的時候apiserver處在阻塞狀態。

三、AuditOptions結構體介紹

1、  PolicyFile引數：日誌審計策略配置檔案，通過這個檔案可以配置哪些資訊會生成日誌審計記錄。

2、  LogOptions引數：表示AuditLogOptions結構體。

3、  WebhookOptions引數：表示AuditWebhookOptions結構體。

 在kubernetes1.7中如果想啟用日誌審計新的功能，那麼需要在啟動kube-apiserver元件時，增加一個新的引數： --feature-gates=AdvancedAuditing=true。

一旦啟用了AdvancedAuditing引數，那麼kubernetes在日誌審計中就可以配置審計策略和審計處理方式。日誌審計策略配置檔案中可以配置不同審計級別策略，包括：

1、  None：與此規則匹配的日誌審計事件不用被記錄。

2、  Metadata：記錄請求的元資料資訊，包括使用者、時間戳、請求型別等資訊。

3、  Request：記錄請求的元資料和請求內容資訊。

4、  RequestResponse：記錄請求的元資料、請求內容資訊、響應內容資訊。

另外一旦啟用了這個引數，日誌審計也不會按照之前每條審計日誌記錄兩行資訊了。日誌審計記錄在不同的階段會記錄不同的資訊，其中包括：

1、  RequestReceived階段：在這個階段，審計處理程式收到請求後立即生成日誌審計事件。

2、  ResponseStarted階段：在這個階段，響應標頭被髮送出去了，但是響應內容還沒有被髮送，此日誌審計記錄在長時間執行的響應時會生成。

3、  ResponseComplete階段：在這個階段，一旦響應內容被髮送出去了，那麼就會生成日誌審計記錄。

4、  Panic階段：當有錯誤發生時，會生成日誌審計記錄。

新特性例子

1、  下面的例子是日誌審計策略配置檔案的配置資訊，表示按照Metadata級別記錄所有請求資訊：

rules:
- level: Metadata

2、  下面的例子是日誌審計策略配置檔案的配置資訊，表示不對使用者system:kube-proxy在endpoints和services兩種型別資源上的資訊進行審計。

rules:
   - level: None
    users:["system:kube-proxy"]
    verbs: ["watch"]
    resources:
    - group: "" #core API group
      resources:["endpoints", "services"]

3、  下面的例子是日誌審計策略配置檔案的配置資訊，表示審計表空間kube-system中configmaps資源型別的請求。

rules:
  # Log the request body ofconfigmap changes in kube-system.
  - level: Request
    resources:
    - group: "" #core API group
      resources:["configmaps"]
    # This rule only appliesto resources in the "kube-system" namespace.
    # The empty string"" can be used to select non-namespaced resources.
    namespaces:["kube-system"]

4、  下面的例子是設定審計處理方式

--audit-webhook-config-file=/etc/kubernetes/audit-webhook-kubeconfig
--audit-webhook-mode=batch

使用batch模式，向/etc/kubernetes/audit-webhook-kubeconfig檔案中配置的服務端傳送日誌審計資訊。