Kubernetes 的審計(jì)（Auditing）功能提供了與安全相關(guān)的、按時(shí)間順序排列的記錄集，用于記錄每個(gè)用戶(hù)、使用 Kubernetes API 的應(yīng)用程序以及控制平面自身引發(fā)的活動(dòng)。Kubernetes 審計(jì)功能可以幫助組織滿(mǎn)足合規(guī)性要求，并加強(qiáng)對(duì)集群安全的管理和監(jiān)控。
審計(jì)功能使得集群管理員能夠回答以下問(wèn)題：
- 發(fā)生了什么？
- 什么時(shí)候發(fā)生的？
- 誰(shuí)觸發(fā)的？
- 活動(dòng)發(fā)生在哪個(gè)（些）對(duì)象上？
- 在哪觀察到的？
- 它從哪觸發(fā)的？
- 活動(dòng)的后續(xù)處理行為是什么？
審計(jì)記錄最初產(chǎn)生于 kube-apiserver 內(nèi)部。每個(gè)請(qǐng)求在不同執(zhí)行階段都會(huì)生成審計(jì)事件；這些審計(jì)事件會(huì)根據(jù)特定策略被預(yù)處理并寫(xiě)入后端。 策略確定要記錄的內(nèi)容和用來(lái)存儲(chǔ)記錄的后端，當(dāng)前的后端支持日志文件和 webhook。
每個(gè)請(qǐng)求都可被記錄其相關(guān)的階段（stage）。已定義的階段有：
- RequestReceived – 此階段對(duì)應(yīng)審計(jì)處理器接收到請(qǐng)求后， 并且在委托給其余處理器之前生成的事件；
- ResponseStarted – 在響應(yīng)消息的頭部發(fā)送后，響應(yīng)消息體發(fā)送前生成的事件。 只有長(zhǎng)時(shí)間運(yùn)行的請(qǐng)求（例如 watch）才會(huì)生成這個(gè)階段；
- ResponseComplete – 當(dāng)響應(yīng)消息體完成并且沒(méi)有更多數(shù)據(jù)需要傳輸?shù)臅r(shí)候；
- Panic – 當(dāng) panic 發(fā)生時(shí)生成。
注意：審計(jì)事件配置 的配置與 Event API 對(duì)象不同。
審計(jì)日志記錄功能會(huì)增加 API server 的內(nèi)存消耗，因?yàn)樾枰獮槊總€(gè)請(qǐng)求存儲(chǔ)審計(jì)所需的某些上下文。 內(nèi)存消耗取決于審計(jì)日志記錄的配置。
一、審計(jì)策略
審計(jì)策略定義了關(guān)于應(yīng)記錄哪些事件以及應(yīng)包含哪些數(shù)據(jù)的規(guī)則。 審計(jì)策略對(duì)象結(jié)構(gòu)定義在 audit.k8s.io API 組。 處理事件時(shí)，將按順序與規(guī)則列表進(jìn)行比較。第一個(gè)匹配規(guī)則設(shè)置事件的審計(jì)級(jí)別（Audit Level）。 已定義的審計(jì)級(jí)別有：
- None – 符合這條規(guī)則的日志將不會(huì)記錄；
- Metadata – 記錄請(qǐng)求的元數(shù)據(jù)（請(qǐng)求的用戶(hù)、時(shí)間戳、資源、動(dòng)詞等等）， 但是不記錄請(qǐng)求或者響應(yīng)的消息體；
- Request – 記錄事件的元數(shù)據(jù)和請(qǐng)求的消息體，但是不記錄響應(yīng)的消息體。 這不適用于非資源類(lèi)型的請(qǐng)求；
- RequestResponse – 記錄事件的元數(shù)據(jù)，請(qǐng)求和響應(yīng)的消息體。這不適用于非資源類(lèi)型的請(qǐng)求。
- 可以使用 –audit-policy-file 標(biāo)志將包含策略的文件傳遞給 kube-apiserver。 如果不設(shè)置該標(biāo)志，則不記錄事件。 注意 rules 字段必須在審計(jì)策略文件中提供。沒(méi)有（0）規(guī)則的策略將被視為非法配置。
以下是一個(gè)審計(jì)策略文件的示例：
apiVersion: audit.k8s.io/v1 # 這是必填項(xiàng)。 kind:?Policy #?不要在?RequestReceived?階段為任何請(qǐng)求生成審計(jì)事件。 omitStages: ??-?"RequestReceived" rules: ??#?在日志中用?RequestResponse?級(jí)別記錄?Pod?變化。 ??-?level:?RequestResponse ????resources: ????-?group:?"" ??????#?資源?"pods"?不匹配對(duì)任何?Pod?子資源的請(qǐng)求， ??????#?這與?RBAC?策略一致。 ??????resources:?["pods"] ??#?在日志中按?Metadata?級(jí)別記錄?"pods/log"、"pods/status"?請(qǐng)求 ??-?level:?Metadata ????resources: ????-?group:?"" ??????resources:?["pods/log",?"pods/status"] ??#?不要在日志中記錄對(duì)名為?"controller-leader"?的?configmap?的請(qǐng)求。 ??-?level:?None ????resources: ????-?group:?"" ??????resources:?["configmaps"] ??????resourceNames:?["controller-leader"] ??#?不要在日志中記錄由?"system:kube-proxy"?發(fā)出的對(duì)端點(diǎn)或服務(wù)的監(jiān)測(cè)請(qǐng)求。 ??-?level:?None ????users:?["system:kube-proxy"] ????verbs:?["watch"] ????resources: ????-?group:?""?#?core?API?組 ??????resources:?["endpoints",?"services"] ??#?不要在日志中記錄對(duì)某些非資源?URL?路徑的已認(rèn)證請(qǐng)求。 ??-?level:?None ????userGroups:?["system:authenticated"] ????nonResourceURLs: ????-?"/api*"?#?通配符匹配。 ????-?"/version" ??#?在日志中記錄?kube-system?中?configmap?變更的請(qǐng)求消息體。 ??-?level:?Request ????resources: ????-?group:?""?#?core?API?組 ??????resources:?["configmaps"] ????#?這個(gè)規(guī)則僅適用于?"kube-system"?名字空間中的資源。 ????#?空字符串?""?可用于選擇非名字空間作用域的資源。 ????namespaces:?["kube-system"] ??#?在日志中用?Metadata?級(jí)別記錄所有其他名字空間中的?configmap?和?secret?變更。 ??-?level:?Metadata ????resources: ????-?group:?""?#?core?API?組 ??????resources:?["secrets",?"configmaps"] ??#?在日志中以?Request?級(jí)別記錄所有其他?core?和?extensions?組中的資源操作。 ??-?level:?Request ????resources: ????-?group:?""?#?core?API?組 ????-?group:?"extensions"?#?不應(yīng)包括在內(nèi)的組版本。 ??#?一個(gè)抓取所有的規(guī)則，將在日志中以?Metadata?級(jí)別記錄所有其他請(qǐng)求。 ??-?level:?Metadata ????#?符合此規(guī)則的?watch?等長(zhǎng)時(shí)間運(yùn)行的請(qǐng)求將不會(huì) ????#?在?RequestReceived?階段生成審計(jì)事件。 ????omitStages: ??????-?"RequestReceived"
可以使用最低限度的審計(jì)策略文件在 Metadata 級(jí)別記錄所有請(qǐng)求：
# 在 Metadata 級(jí)別為所有請(qǐng)求生成日志 apiVersion: audit.k8s.io/v1beta1 kind: Policy rules: - level: Metadata
如果在打磨自己的審計(jì)配置文件，可以使用為 Google Container-Optimized OS 設(shè)計(jì)的審計(jì)配置作為出發(fā)點(diǎn)?？梢詤⒖?configure-helper.sh 腳本，該腳本能夠生成審計(jì)策略文件。可以直接在腳本中看到審計(jì)策略的絕大部份內(nèi)容。
二、審計(jì)后端
審計(jì)后端實(shí)現(xiàn)將審計(jì)事件導(dǎo)出到外部存儲(chǔ)。kube-apiserver 默認(rèn)提供兩個(gè)后端：
- Log 后端，將事件寫(xiě)入到文件系統(tǒng)；
- Webhook 后端，將事件發(fā)送到外部 HTTP API。
在這所有情況下，審計(jì)事件均遵循 Kubernetes API 在 audit.k8s.io API 組 中定義的結(jié)構(gòu)。
對(duì)于 patch 請(qǐng)求，請(qǐng)求的消息體需要是設(shè)定 patch 操作的 JSON 所構(gòu)成的一個(gè)串， 而不是一個(gè)完整的 Kubernetes API 對(duì)象的 JSON 串。 例如，以下的示例是一個(gè)合法的 patch 請(qǐng)求消息體，該請(qǐng)求對(duì)應(yīng) /apis/batch/v1/namespaces/some-namespace/jobs/some-job-name：
[
{
"op": "replace",
"path": "/spec/parallelism",
"value": 0
},
{
"op": "remove",
"path": "/spec/template/spec/containers/0/terminationMessagePolicy"
}
]
1、Log后端
Log 后端將審計(jì)事件寫(xiě)入 JSONlines 格式的文件。 可以使用以下 kube-apiserver 標(biāo)志配置 Log 審計(jì)后端：
- –audit-log-path 指定用來(lái)寫(xiě)入審計(jì)事件的日志文件路徑。不指定此標(biāo)志會(huì)禁用日志后端。- 意味著標(biāo)準(zhǔn)化；
- –audit-log-maxage 定義保留舊審計(jì)日志文件的最大天數(shù)；
- –audit-log-maxbackup 定義要保留的審計(jì)日志文件的最大數(shù)量；
- –audit-log-maxsize 定義審計(jì)日志文件輪轉(zhuǎn)之前的最大大小（兆字節(jié)）。
如果集群控制面以 Pod 的形式運(yùn)行 kube-apiserver，記得要通過(guò) hostPath 卷來(lái)訪問(wèn)策略文件和日志文件所在的目錄，這樣審計(jì)記錄才會(huì)持久保存下來(lái)。例如：
- --audit-policy-file=/etc/kubernetes/audit-policy.yaml - --audit-log-path=/var/log/kubernetes/audit/audit.log
接下來(lái)掛載數(shù)據(jù)卷：
... volumeMounts: - mountPath: /etc/kubernetes/audit-policy.yaml name: audit readOnly: true - mountPath: /var/log/kubernetes/audit/ name: audit-log readOnly: false
最后配置 hostPath：
... volumes: - name: audit hostPath: path: /etc/kubernetes/audit-policy.yaml type: File - name: audit-log hostPath: path: /var/log/kubernetes/audit/ type: DirectoryOrCreate
2、Webhook 后端
Webhook 后端將審計(jì)事件發(fā)送到遠(yuǎn)程 Web API，該遠(yuǎn)程 API 應(yīng)該暴露與 kube-apiserver 形式相同的 API，包括其身份認(rèn)證機(jī)制?？梢允褂萌缦?kube-apiserver 標(biāo)志來(lái)配置 Webhook 審計(jì)后端：
- –audit-webhook-config-file 設(shè)置 Webhook 配置文件的路徑。Webhook 配置文件實(shí)際上是一個(gè) kubeconfig 文件；
- –audit-webhook-initial-backoff 指定在第一次失敗后重發(fā)請(qǐng)求等待的時(shí)間。隨后的請(qǐng)求將以指數(shù)退避重試。
- Webhook 配置文件使用 kubeconfig 格式指定服務(wù)的遠(yuǎn)程地址和用于連接它的憑據(jù)。
三、事件批處理
日志和 Webhook 后端都支持批處理。以 Webhook 為例，以下是可用參數(shù)列表。要獲取日志 后端的同樣參數(shù)，請(qǐng)?jiān)趨?shù)名稱(chēng)中將 webhook 替換為 log。 默認(rèn)情況下，在 webhook 中批處理是被啟用的，在 log 中批處理是被禁用的。 同樣，默認(rèn)情況下，在 webhook 中啟用帶寬限制，在 log 中禁用帶寬限制。
1、–audit-webhook-mode 定義緩存策略，可選值如下：
- batch – 以批處理緩存事件和異步的過(guò)程。這是默認(rèn)值；
- blocking – 在 API 服務(wù)器處理每個(gè)單獨(dú)事件時(shí)，阻塞其響應(yīng)；
- blocking-strict – 與 blocking 相同，不過(guò)當(dāng)審計(jì)日志在 RequestReceived 階段失敗時(shí)，整個(gè) API 服務(wù)請(qǐng)求會(huì)失效。
以下參數(shù)僅用于 batch 模式：
2、–audit-webhook-batch-buffer-size 定義 batch 之前要緩存的事件數(shù)。 如果傳入事件的速率溢出緩存區(qū)，則會(huì)丟棄事件；
3、–audit-webhook-batch-max-size 定義一個(gè) batch 中的最大事件數(shù)；
4、–audit-webhook-batch-max-wait 無(wú)條件 batch 隊(duì)列中的事件前等待的最大事件；
5、–audit-webhook-batch-throttle-qps 每秒生成的最大批次數(shù)；
6、–audit-webhook-batch-throttle-burst 在達(dá)到允許的 QPS 前，同一時(shí)刻允許存在的最大 batch 生成數(shù)。
四、參數(shù)調(diào)整
需要設(shè)置參數(shù)以適應(yīng) API 服務(wù)器上的負(fù)載。
例如，如果 kube-apiserver 每秒收到 100 個(gè)請(qǐng)求，并且每個(gè)請(qǐng)求僅在 ResponseStarted 和 ResponseComplete 階段進(jìn)行審計(jì)，則應(yīng)該考慮每秒生成約 200 個(gè)審計(jì)事件。 假設(shè)批處理中最多有 100 個(gè)事件，則應(yīng)將限制級(jí)別設(shè)置為每秒至少 2 個(gè)查詢(xún)。 假設(shè)后端最多需要 5 秒鐘來(lái)寫(xiě)入事件，應(yīng)該設(shè)置緩沖區(qū)大小以容納最多 5 秒的事件， 即 10 個(gè) batch，即 1000 個(gè)事件。
但是，在大多數(shù)情況下，默認(rèn)參數(shù)應(yīng)該足夠了，不必手動(dòng)設(shè)置它們。 可以查看 kube-apiserver 公開(kāi)的以下 Prometheus 指標(biāo)，并在日志中監(jiān)控審計(jì)子系統(tǒng)的狀態(tài)。
- apiserver_audit_event_total 包含所有暴露的審計(jì)事件數(shù)量的指標(biāo)；
- apiserver_audit_error_total 在暴露時(shí)由于發(fā)生錯(cuò)誤而被丟棄的事件的數(shù)量。
日志后端和 Webhook 后端都支持限制所輸出的事件大小。 例如，下面是可以為日志后端配置的標(biāo)志列表：
- audit-log-truncate-enabled：是否棄用事件和批次的截?cái)嗵幚恚?/li>
- audit-log-truncate-max-batch-size：向下層后端發(fā)送的各批次的最大字節(jié)數(shù)；
- audit-log-truncate-max-event-size：向下層后端發(fā)送的審計(jì)事件的最大字節(jié)數(shù)。
默認(rèn)情況下，截?cái)嗖僮髟?webhook 和 log 后端都是被禁用的，集群管理員需要設(shè)置 audit-log-truncate-enabled 或 audit-webhook-truncate-enabled 標(biāo)志來(lái)啟用此操作。
