建站
咨詢
售后
建站咨詢
新聞中心
審計(jì)
FEATURE STATE: Kubernetes v1.24 [beta]
為金口河等地區(qū)用戶提供了全套網(wǎng)頁設(shè)計(jì)制作服務(wù)，及金口河網(wǎng)站建設(shè)行業(yè)解決方案。主營業(yè)務(wù)為成都網(wǎng)站設(shè)計(jì)、成都做網(wǎng)站、金口河網(wǎng)站設(shè)計(jì)，以傳統(tǒng)方式定制建設(shè)網(wǎng)站，并提供域名空間備案等一條龍服務(wù)，秉承以專業(yè)、用心的態(tài)度為用戶提供真誠的服務(wù)。我們深信只要達(dá)到每一位用戶的要求，就會(huì)得到認(rèn)可，從而選擇與我們長期合作。這樣，我們也可以走得更遠(yuǎn)！
Kubernetes 審計(jì)（Auditing） 功能提供了與安全相關(guān)的、按時(shí)間順序排列的記錄集， 記錄每個(gè)用戶、使用 Kubernetes API 的應(yīng)用以及控制面自身引發(fā)的活動(dòng)。
審計(jì)功能使得集群管理員能夠回答以下問題：
- 發(fā)生了什么？
- 什么時(shí)候發(fā)生的？
- 誰觸發(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ù)處理并寫入后端。策略確定要記錄的內(nè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ā)送前生成的事件。 只有長時(shí)間運(yùn)行的請(qǐng)求（例如 watch）才會(huì)生成這個(gè)階段。 - ?
ResponseComplete?- 當(dāng)響應(yīng)消息體完成并且沒有更多數(shù)據(jù)需要傳輸?shù)臅r(shí)候。 - ?
Panic?- 當(dāng) panic 發(fā)生時(shí)生成。
Note: 審計(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)求的用戶、時(shí)間戳、資源、動(dòng)詞等等）， 但是不記錄請(qǐng)求或者響應(yīng)的消息體。 - ?
Request?- 記錄事件的元數(shù)據(jù)和請(qǐng)求的消息體，但是不記錄響應(yīng)的消息體。 這不適用于非資源類型的請(qǐng)求。 - ?
RequestResponse?- 記錄事件的元數(shù)據(jù)，請(qǐng)求和響應(yīng)的消息體。這不適用于非資源類型的請(qǐng)求。
你可以使用 ?--audit-policy-file? 標(biāo)志將包含策略的文件傳遞給 ?kube-apiserver?。 如果不設(shè)置該標(biāo)志，則不記錄事件。 注意 ?rules ?字段 必須 在審計(jì)策略文件中提供。沒有（0）規(guī)則的策略將被視為非法配置。
以下是一個(gè)審計(jì)策略文件的示例：
apiVersion: audit.k8s.io/v1 # This is required.
kind: Policy
# Don't generate audit events for all requests in RequestReceived stage.
omitStages:
- "RequestReceived"
rules:
# Log pod changes at RequestResponse level
- level: RequestResponse
resources:
- group: ""
# Resource "pods" doesn't match requests to any subresource of pods,
# which is consistent with the RBAC policy.
resources: ["pods"]
# Log "pods/log", "pods/status" at Metadata level
- level: Metadata
resources:
- group: ""
resources: ["pods/log", "pods/status"]
# Don't log requests to a configmap called "controller-leader"
- level: None
resources:
- group: ""
resources: ["configmaps"]
resourceNames: ["controller-leader"]
# Don't log watch requests by the "system:kube-proxy" on endpoints or services
- level: None
users: ["system:kube-proxy"]
verbs: ["watch"]
resources:
- group: "" # core API group
resources: ["endpoints", "services"]
# Don't log authenticated requests to certain non-resource URL paths.
- level: None
userGroups: ["system:authenticated"]
nonResourceURLs:
- "/api*" # Wildcard matching.
- "/version"
# Log the request body of configmap changes in kube-system.
- level: Request
resources:
- group: "" # core API group
resources: ["configmaps"]
# This rule only applies to resources in the "kube-system" namespace.
# The empty string "" can be used to select non-namespaced resources.
namespaces: ["kube-system"]
# Log configmap and secret changes in all other namespaces at the Metadata level.
- level: Metadata
resources:
- group: "" # core API group
resources: ["secrets", "configmaps"]
# Log all other resources in core and extensions at the Request level.
- level: Request
resources:
- group: "" # core API group
- group: "extensions" # Version of group should NOT be included.
# A catch-all rule to log all other requests at the Metadata level.
- level: Metadata
# Long-running requests like watches that fall under this rule will not
# generate an audit event in RequestReceived.
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)容。
你也可以參考 ?Policy ?配置參考 以獲取有關(guān)已定義字段的詳細(xì)信息。
審計(jì)后端
審計(jì)后端實(shí)現(xiàn)將審計(jì)事件導(dǎo)出到外部存儲(chǔ)。?Kube-apiserver? 默認(rèn)提供兩個(gè)后端：
- Log 后端，將事件寫入到文件系統(tǒng)
- Webhook 后端，將事件發(fā)送到外部 HTTP API
在這所有情況下，審計(jì)事件均遵循 Kubernetes API 在 ?audit.k8s.io? API 組 中定義的結(jié)構(gòu)。
Note:
對(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" } ]
Log 后端
Log 后端將審計(jì)事件寫入 JSONlines 格式的文件。 你可以使用以下 ?kube-apiserver? 標(biāo)志配置 Log 審計(jì)后端：
- ?
--audit-log-path? 指定用來寫入審計(jì)事件的日志文件路徑。不指定此標(biāo)志會(huì)禁用日志后端。?-? 意味著標(biāo)準(zhǔn)化 - ?
--audit-log-maxage? 定義保留舊審計(jì)日志文件的最大天數(shù) - ?
--audit-log-maxbackup? 定義要保留的審計(jì)日志文件的最大數(shù)量 - ?
--audit-log-maxsize? 定義審計(jì)日志文件的最大大小（兆字節(jié)）
如果你的集群控制面以 Pod 的形式運(yùn)行 kube-apiserver，記得要通過 ?hostPath ?卷來訪問策略文件和日志文件所在的目錄，這樣審計(jì)記錄才會(huì)持久保存下來。例如：
--audit-policy-file=/etc/kubernetes/audit-policy.yaml
--audit-log-path=/var/log/kubernetes/audit/audit.log接下來掛載數(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: DirectoryOrCreateWebhook 后端
Webhook 后端將審計(jì)事件發(fā)送到遠(yuǎn)程 Web API，該遠(yuǎn)程 API 應(yīng)該暴露與 ?kube-apiserver? 形式相同的 API，包括其身份認(rèn)證機(jī)制。你可以使用如下 kube-apiserver 標(biāo)志來配置 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ù)名稱中將 ?webhook ?替換為 ?log?。 默認(rèn)情況下，在 ?webhook ?中批處理是被啟用的，在 ?log ?中批處理是被禁用的。 同樣，默認(rèn)情況下，在 ?webhook ?中啟用帶寬限制，在 ?log ?中禁用帶寬限制。
- ?
--audit-webhook-mode? 定義緩存策略，可選值如下： - ?
batch? - 以批處理緩存事件和異步的過程。這是默認(rèn)值。 - ?
blocking? - 在 API 服務(wù)器處理每個(gè)單獨(dú)事件時(shí)，阻塞其響應(yīng)。 - ?
blocking-strict? - 與 ?blocking?相同，不過當(dāng)審計(jì)日志在 RequestReceived 階段 失敗時(shí)，整個(gè) API 服務(wù)請(qǐng)求會(huì)失效。
以下參數(shù)僅用于 ?batch ?模式。
- ?
--audit-webhook-batch-buffer-size? 定義 batch 之前要緩存的事件數(shù)。 如果傳入事件的速率溢出緩存區(qū)，則會(huì)丟棄事件。 - ?
--audit-webhook-batch-max-size? 定義一個(gè) batch 中的最大事件數(shù)。 - ?
--audit-webhook-batch-max-wait? 無條件 batch 隊(duì)列中的事件前等待的最大事件。 - ?
--audit-webhook-batch-throttle-qps? 每秒生成的最大批次數(shù)。 - ?
--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è)查詢。 假設(shè)后端最多需要 5 秒鐘來寫入事件，你應(yīng)該設(shè)置緩沖區(qū)大小以容納最多 5 秒的事件， 即 10 個(gè) batch，即 1000 個(gè)事件。
但是，在大多數(shù)情況下，默認(rèn)參數(shù)應(yīng)該足夠了，你不必手動(dòng)設(shè)置它們。 你可以查看 kube-apiserver 公開的以下 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ù)量。
日志條目截?cái)?nbsp;
日志后端和 Webhook 后端都支持限制所輸出的事件的尺寸。 例如，下面是可以為日志后端配置的標(biāo)志列表：
- ?
audit-log-truncate-enabled?：是否棄用事件和批次的截?cái)嗵幚怼? - ?
audit-log-truncate-max-batch-size?：向下層后端發(fā)送的各批次的最大尺寸字節(jié)數(shù)。 - ?
audit-log-truncate-max-event-size?：向下層后端發(fā)送的審計(jì)事件的最大尺寸字節(jié)數(shù)。
默認(rèn)情況下，截?cái)嗖僮髟?nbsp;?webhook ?和 ?log ?后端都是被禁用的，集群管理員需要設(shè)置 ?audit-log-truncate-enabled? 或 ?audit-webhook-truncate-enabled? 標(biāo)志來啟用此操作。
分享文章：創(chuàng)新互聯(lián)kubernetes教程：Kubernetes審計(jì)
當(dāng)前地址：http://www.dlmjj.cn/article/cogiode.html
