Kubernetes1.7 新特性:日誌審計變化_Kubernetes中文社群
背景概念
出於安全方面的考慮，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檔案中配置的服務端傳送日誌審計資訊。