Kubernetes 策略管理引擎 - Kyverno
Kyverno 是來自 Nirmata 的開源項目，后來捐贈給了 CNCF。Kyverno 是一個具有驗證和變異能力的 Kubernetes 策略引擎，但是它還有生成資源的功能，還加入了 API 對象查詢的能力。Kyverno 原本就是為 Kubernetes 編寫的，除了對象生成功能之外，無需專用語言即可編寫策略。
同樣 Kyverno 在 Kubernetes 集群中也是作為動態(tài)準(zhǔn)入控制器運行的。Kyverno 從 kube-apiserver 接收驗證和修改準(zhǔn)入 webhook HTTP 回調(diào)，并應(yīng)用匹配策略返回執(zhí)行準(zhǔn)入策略或拒絕請求的結(jié)果。Kyverno 策略可以使用資源 Kind、name 和標(biāo)簽選擇器匹配資源，而且名稱中支持通配符。
策略執(zhí)行是通過 Kubernetes events 來捕獲的，Kyverno 還報告現(xiàn)有資源的策略違規(guī)行為。下圖顯示了 Kyverno 的整體架構(gòu)：
Kyverno架構(gòu)
Kyverno 的高可用安裝可以通過運行多個副本來完成，并且 Kyverno 的每個副本將具有多個執(zhí)行不同功能的控制器。Webhook 處理來自 Kubernetes APIServer 的 AdmissionReview 請求，其 Monitor 組件創(chuàng)建和管理所需的配置。PolicyController watch 策略資源并根據(jù)配置的掃描間隔啟動后臺掃描，GenerateController 管理生成資源的生命周期。
安裝
首先需要保證你的 Kubernetes 集群版本必須高于 v1.14，要安裝的版本也和 Kubernetes 版本有關(guān)系。
兼容版本
我們這里已經(jīng)是 v1.28.x 版本了，所以選擇安裝最新的 1.11.4 版本即可。
你可以選擇直接從最新版本的資源清單安裝 Kyverno，直接執(zhí)行下面的命令即可：
? kubectl create -f https://github.com/kyverno/kyverno/releases/download/v1.11.3/install.yaml此外同樣可以使用 Helm 來進行一鍵安裝：
? helm repo add kyverno https://kyverno.github.io/kyverno/
? helm repo update
# Install the Kyverno Helm chart into a new namespace called "kube-kyverno"
? helm upgrade --install kyverno kyverno/kyverno -n kube-kyverno --create-namespace
Release "kyverno" does not exist. Installing it now.
NAME: kyverno
LAST DEPLOYED: Fri Apr 12 10:57:03 2024
NAMESPACE: kube-kyverno
STATUS: deployed
REVISION: 1
NOTES:
Chart version: 3.1.4
Kyverno version: v1.11.4
Thank you for installing kyverno! Your release is named kyverno.
The following components have been installed in your cluster:
- CRDs
- Admission controller
- Reports controller
- Cleanup controller
- Background controller
?? WARNING: Setting the admission controller replica count below 3 means Kyverno is not running in high availability mode.
?? Note: There is a trade-off when deciding which approach to take regarding Namespace exclusions. Please see the documentation at https://kyverno.io/docs/installation/#security-vs-operability to understand the risks.安裝完成會創(chuàng)建一個 kube-kyverno 命名空間，同樣也包含一些相關(guān)的 CRD：
? kubectl get pods -n kube-kyverno
NAME READY STATUS RESTARTS AGE
kyverno-admission-controller-5bfb8878f5-gd77c 1/1 Running 0 22m
kyverno-background-controller-584b969d8c-l2m76 1/1 Running 0 22m
kyverno-cleanup-admission-reports-28548190-94s8h 0/1 Completed 0 9m24s
kyverno-cleanup-cluster-admission-reports-28548190-m5gkc 0/1 Completed 0 9m24s
kyverno-cleanup-controller-c9cc65b74-tvzdh 1/1 Running 0 22m
kyverno-reports-controller-757cc45589-2vjqd 1/1 Running 0 22m
? kubectl get validatingwebhookconfiguration
NAME WEBHOOKS AGE
kyverno-cleanup-validating-webhook-cfg 1 18m
kyverno-exception-validating-webhook-cfg 1 13m
kyverno-policy-validating-webhook-cfg 1 13m
kyverno-resource-validating-webhook-cfg 0 13m
kyverno-ttl-validating-webhook-cfg 1 18m
? kubectl get mutatingwebhookconfigurations
NAME WEBHOOKS AGE
kyverno-policy-mutating-webhook-cfg 1 14m
kyverno-resource-mutating-webhook-cfg 0 14m
kyverno-verify-mutating-webhook-cfg 1 14m
? kubectl get crd |grep kyverno
admissionreports.kyverno.io 2024-04-12T02:57:06Z
backgroundscanreports.kyverno.io 2024-04-12T02:57:06Z
cleanuppolicies.kyverno.io 2024-04-12T02:57:06Z
clusteradmissionreports.kyverno.io 2024-04-12T02:57:06Z
clusterbackgroundscanreports.kyverno.io 2024-04-12T02:57:06Z
clustercleanuppolicies.kyverno.io 2024-04-12T02:57:06Z
clusterpolicies.kyverno.io 2024-04-12T02:57:07Z
policies.kyverno.io 2024-04-12T02:57:07Z
policyexceptions.kyverno.io 2024-04-12T02:57:06Z
updaterequests.kyverno.io 2024-04-12T02:57:06Z可以看出安裝完成后創(chuàng)建了幾個 validatingwebhookconfiguration 與 mutatingwebhookconfigurations 對象。
策略與規(guī)則
使用 Kyverno 其實就是對策略和規(guī)則的應(yīng)用，Kyverno 策略是規(guī)則的集合，每個規(guī)則都包含一個 match 聲明、一個可選的 exclude 聲明以及 validate、mutate、generate 或 verifyImages 聲明之一組成，每個規(guī)則只能包含一個 validate、mutate、generate 或 verifyImages 子聲明。
Kyverno策略
策略可以定義為集群范圍的資源（ClusterPolicy）或命名空間級別資源（Policy）。
- Policy 將僅適用于定義它們的 namespace 內(nèi)的資源。
- ClusterPolicy 應(yīng)用于匹配跨所有 namespace 的資源。
策略定義
編寫策略其實就是定義 Policy 或者 ClusterPolicy 對象。
驗證資源
驗證規(guī)則基本上是我們使用最常見和最實用的規(guī)則類型，當(dāng)用戶或進程創(chuàng)建新資源時，Kyverno 將根據(jù)驗證規(guī)則檢查該資源的屬性，如果驗證通過，則允許創(chuàng)建資源。如果驗證失敗，則創(chuàng)建被阻止。比如現(xiàn)在我們添加一個策略，要求所有的 pod 都包含一個 kyverno 的標(biāo)簽：
# kyverno-require-label.yaml
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
name: require-label-policy
spec:
validationFailureAction: Enforce
rules:
- name: check-for-labels
match:
resources:
kinds:
- Pod
validate:
message: "label 'kyverno' is required"
pattern:
metadata:
labels:
kyverno: "?*"上面策略文件中添加了一個 validatinotallow=[Audit, Enforce] 屬性：
- 當(dāng)處于 Audit 模式下，每當(dāng)創(chuàng)建違反規(guī)則集的一個或多個規(guī)則的資源時，會允許 admission review 請求，并將結(jié)果添加到報告中。
- 當(dāng)處于 Enforce 模式下，資源在創(chuàng)建時立即被阻止，報告中不會有。
然后就是下面使用 rules 屬性定義的規(guī)則集合，match 用于表示匹配的資源資源，validate 表示驗證方式，這里我們定義 kyverno: "?*" 這樣的標(biāo)簽表示必須有這樣的一個標(biāo)簽 key。
直接應(yīng)用上面的策略對象即可：
? kubectl apply -f kyverno-require-label.yaml
clusterpolicy.kyverno.io/require-label-policy created
? kubectl get clusterpolicy
NAME ADMISSION BACKGROUND VALIDATE ACTION READY AGE MESSAGE
require-label-policy true true Enforce True 37s Ready現(xiàn)在我們添加一個不帶標(biāo)簽 kyverno 的 Pod：
? kubectl run busybox --image=busybox:1.28.3 --restart=Never -- sleep 1000000
Error from server: admission webhook "validate.kyverno.svc-fail" denied the request:
resource Pod/default/busybox was blocked due to the following policies
require-label-policy:
check-for-labels: 'validation error: label ''kyverno'' is required. rule check-for-labels
failed at path /metadata/labels/kyverno/'可以看到提示，需要一個 kyverno 標(biāo)簽，同樣我們也可以通過查看 Events 事件來了解策略應(yīng)用情況：
? kubectl get events -A -w
......
kube-system 41s Warning PolicyViolation pod/kube-scheduler-master policy require-label-policy/check-for-labels fail: validation error: label 'kyverno' is required. rule check-for-labels failed at path /metadata/labels/kyverno/
kube-system 41s Warning PolicyViolation pod/kube-sealos-lvscare-node1 policy require-label-policy/check-for-labels fail: validation error: label 'kyverno' is required. rule check-for-labels failed at path /metadata/labels/
kube-system 41s Warning PolicyViolation pod/kube-sealos-lvscare-node2 policy require-label-policy/check-for-labels fail: validation error: label 'kyverno' is required. rule check-for-labels failed at path /metadata/labels/如果創(chuàng)建的 Pod 帶有 kyverno 標(biāo)簽則可以正常創(chuàng)建：
? kubectl run busybox --image=busybox:1.28.3 --labels kyverno=demo --restart=Never -- sleep 1000000
pod/busybox created如果將 validationFailureAction 的值更改為 Audit，則即使我們創(chuàng)建的 Pod 不帶有 kyverno 標(biāo)簽，也可以創(chuàng)建成功，但是我們可以在 PolicyReport 對象中看到對應(yīng)的違規(guī)報告：
? kubectl get policyreports
NAME KIND NAME PASS FAIL WARN ERROR SKIP AGE
92916c69-a769-4064-a82f-0cbedd14de3a Deployment nfs-client-provisioner 0 1 0 0 0 6m3s
e0860e6f-7296-492f-8cba-a411f8305885 ReplicaSet nfs-client-provisioner-5f6f85d8c4 0 1 0 0 0 6m3s
e55af9b6-30f5-4708-9308-63f58063bfea Pod busybox 0 1 0 0 0 10s
? kubectl describe policyreports |grep "Result: \+fail" -B10
UID: 1cc048ee-6a63-4824-bdbe-3234a69d0379
Results:
Message: validation error: label 'kyverno' is required. rule check-for-labels failed at path /metadata/labels/kyverno/
Policy: require-label-policy
Result: fail
Rule: check-for-labels
Scored: true
Source: kyverno
Timestamp:
Nanos: 0
Seconds: 1712902797從上面的報告資源中可以看到違反策略的資源對象。
變更規(guī)則
變更規(guī)則可以用于修改匹配到規(guī)則的資源（比如規(guī)則設(shè)置了 metadata 字段可以和資源的 metadata 進行合并），就是根據(jù)我們設(shè)置的規(guī)則來修改對應(yīng)的資源。
比如現(xiàn)在我們添加如下所示一個策略，給所有包含 nginx 鏡像的 pod 都加上一個標(biāo)簽（kyverno=nginx）：
# kyverno-mutate-label.yaml
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
name: nginx-label-policy
spec:
rules:
- name: nginx-label
match:
resources:
kinds:
- Pod
mutate:
patchStrategicMerge:
metadata:
labels:
kyverno: nginx
spec:
(containers):
- (image): "*nginx*" # 容器鏡像包含 nginx 即可直接應(yīng)用上面這個策略對象即可：
? kubectl apply -f kyverno-mutate-label.yaml
clusterpolicy.kyverno.io/nginx-label-policy created
? kubectl get clusterpolicy
NAME ADMISSION BACKGROUND VALIDATE ACTION READY AGE MESSAGE
nginx-label-policy true true Audit True 4s Ready現(xiàn)在我們使用 nginx 鏡像直接創(chuàng)建一個 Pod：
? kubectl run --image=nginx:1.7.9 nginx
pod/nginx created
? kubectl get pod nginx --show-labels
NAME READY STATUS RESTARTS AGE LABELS
nginx 1/1 Running 0 11s kyverno=nginx,run=nginx可以看到 Pod 創(chuàng)建成功后包含了一個 kyverno=nginx 標(biāo)簽，由于有 kyverno 標(biāo)簽，所以上面的驗證策略也是通過的，可以正常創(chuàng)建。
生成資源
生成規(guī)則可用于在創(chuàng)建新資源或更新源時創(chuàng)建其他資源，例如為命名空間創(chuàng)建新 RoleBindings 或 Secret 等。
比如現(xiàn)在我們一個需求是將某個 Secret 同步到其他命名空間中去（比如 TLS 密鑰、鏡像倉庫認證信息），手動復(fù)制這些 Secret 比較麻煩，則我們可以使用 Kyverno 來創(chuàng)建一個策略幫助我們同步這些 Secret。比如在 default 命名空間中有一個名為 regcred 的 Secret 對象，需要復(fù)制到另外的命名空間，如果源 Secret 發(fā)生更改，它還將向復(fù)制的 Secret 同步更新。
# kyverno-generate-secret.yaml
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
name: sync-secrets-policy
spec:
rules:
- name: sync-image-pull-secret
match:
any:
- resources:
kinds:
- Namespace
generate: # 生成的資源對象
apiVersion: v1
kind: Secret
name: regcred
namespace: "{{request.object.metadata.name}}" # 獲取目標(biāo)命名空間
synchronize: true
clone:
namespace: default
name: regcred先在 default 命名空間中準(zhǔn)備我們的 Secret 對象：
? kubectl create secret docker-registry regcred --docker-server=DOCKER_REGISTRY_SERVER --docker-username=DOCKER_USER --docker-password=DOCKER_PASSWORD --docker-email=DOCKER_EMAIL
secret/regcred created然后應(yīng)用上面的同步 Secret 策略：
? kubectl apply -f kyverno-generate-secret.yaml
clusterpolicy.kyverno.io/sync-secrets-policy created
? kubectl get clusterpolicy
NAME ADMISSION BACKGROUND VALIDATE ACTION READY AGE MESSAGE
sync-secrets-policy true true Audit True 19s Ready現(xiàn)在我們創(chuàng)建一個新的命名空間：
? kubectl create ns test
namespace/test created
? kubectl get secret -n test
NAME TYPE DATA AGE
regcred kubernetes.io/dockerconfigjson 1 6s可以看到在新建的命名空間中多了一個 regcred 的 Secret 對象。
又比如默認情況下，Kubernetes 允許集群內(nèi)所有 Pod 之間進行通信。必須使用 NetworkPolicy 資源和支持 NetworkPolicy 的 CNI 插件來限制通信。我們可以為每個命名空間配置默認 NetworkPolicy，以默認拒絕命名空間中 Pod 的所有入口和出口流量。然后再配置額外的 NetworkPolicy 資源，以允許從選定來源到應(yīng)用程序 Pod 的所需流量。這個時候我們也可以創(chuàng)建一個 Kyverno 策略來幫助我們自動創(chuàng)建這個默認的 NetworkPolicy。
# kyverno-add-networkpolicy.yaml
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
name: add-networkpolicy
spec:
rules:
- name: default-deny
match:
any:
- resources:
kinds:
- Namespace
generate:
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
name: default-deny
namespace: "{{request.object.metadata.name}}"
synchronize: true
data:
spec:
# select all pods in the namespace
podSelector: {}
# deny all traffic
policyTypes:
- Ingress
- Egress上面的這個策略文件中定義了一個 default-deny 的 NetworkPolicy，這個 NetworkPolicy 將在創(chuàng)建新命名空間時拒絕所有流量。
清理資源
Kyverno 能夠以兩種不同的方式清理（即刪除）集群中的現(xiàn)有資源。第一種方法是通過 CleanupPolicy 或 ClusterCleanupPolicy 中的聲明性策略定義。第二種方法是通過添加到資源的保留生存時間 (TTL) 標(biāo)簽。
與驗證、變異、生成或驗證資源中的鏡像的其他策略類似，Kyverno 可以通過定義稱為 CleanupPolicy 的新策略類型來清理資源。清理策略有集群范圍和命名空間兩種類型。清理策略使用熟悉的 match/exclude 屬性來選擇和排除要進行清理過程的資源。Conditions{} 屬性（可選）使用類似于前提條件和拒絕規(guī)則中的通用表達式來查詢所選資源的內(nèi)容，以優(yōu)化選擇過程。上下文變量（可選）可用于從其他資源獲取數(shù)據(jù)以納入清理過程。最后，schedule 字段以 cron 格式定義規(guī)則應(yīng)運行的時間。
比如如果每 5 分鐘的定時任務(wù)中發(fā)現(xiàn)副本數(shù)量少于兩個，則此清理策略將刪除具有標(biāo)簽 canremove:true的 Deployment。
apiVersion: kyverno.io/v2beta1
kind: ClusterCleanupPolicy
metadata:
name: cleandeploy
spec:
match:
any:
- resources:
kinds:
- Deployment
selector:
matchLabels:
canremove: "true"
conditions:
any:
- key: "{{ target.spec.replicas }}"
operator: LessThan
value: 2
schedule: "*/5 * * * *"由于 Kyverno 遵循最小權(quán)限原則，因此根據(jù)希望刪除的資源，可能需要向清理控制器授予額外的權(quán)限。Kyverno 將在安裝新的清理策略時通過驗證這些權(quán)限來協(xié)助通知您是否需要額外的權(quán)限。比如下面的 ClusterRole 表示允許 Kyverno 清理 Pod 的權(quán)限聲明：
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
labels:
app.kubernetes.io/component: cleanup-controller
app.kubernetes.io/instance: kyverno
app.kubernetes.io/part-of: kyverno
name: kyverno:cleanup-pods
rules:
- apiGroups:
- ""
resources:
- pods
verbs:
- get
- watch
- list
- delete除了可以聲明性定義要刪除哪些資源以及何時刪除它們的策略之外，還有一種清理方式就是使用一個名為 cleanup.kyverno.io/ttl 的標(biāo)簽來明確標(biāo)記需要刪除的資源，該標(biāo)簽可以分配給任何資源，只要 Kyverno 具有刪除該資源所需的權(quán)限，它將在指定時間刪除。例如，創(chuàng)建下面的 Pod 將導(dǎo)致 Kyverno 在兩分鐘后清理它，并且不存在清理策略。
apiVersion: v1
kind: Pod
metadata:
labels:
cleanup.kyverno.io/ttl: 2m
name: foo
spec:
containers:
- args:
- sleep
- 1d
image: busybox:1.35
name: foo策略變量
變量通過啟用對策略定義中的數(shù)據(jù)、準(zhǔn)入審核請求以及 ConfigMap、Kubernetes API Server、OCI 鏡像倉庫甚至外部服務(wù)調(diào)用等外部數(shù)據(jù)源的引用，使策略變得更加智能和可重用。
變量存儲為 JSON，Kyverno 支持使用 JMESPath 來選擇和轉(zhuǎn)換 JSON 數(shù)據(jù)。使用 JMESPath，來自數(shù)據(jù)源的值以 {{key1.key2.key3}} 的格式引用。例如，要在 kubectl apply 操作期間引用新/傳入資源的名稱，可以將其編寫為變量引用：{{request.object.metadata.name}}。在處理規(guī)則之前，策略引擎將用變量值替換任何格式為 {{ <JMESPath> }} 的值。變量可用于 Kyverno 規(guī)則或策略中的大多數(shù)位置，但匹配或排除語句中除外。
預(yù)定義變量
Kyverno 會自動創(chuàng)建一些有用的變量并使其在規(guī)則中可用：
- serviceAccountName：userName：例如當(dāng)處理來自 system:serviceaccount:nirmata:user1 的請求時，Kyverno 會將值 user1 存儲在變量 serviceAccountName 中。
- serviceAccountNamespace：ServiceAccount 的 namespace 部分。例如，當(dāng)處理來自 system:serviceaccount:nirmata:user1 的請求時，Kyverno 會將 nirmata 存儲在變量 serviceAccountNamespace 中。
- request.roles：存儲在給定帳戶可能擁有的數(shù)組中的角色列表。例如，["foo:dave"]。
- request.clusterRoles：存儲在數(shù)組中的集群角色列表。例如，["dave-admin"，"system：basic-user"，"system：discovery"，"system：public-info-viewer"]。
- images：容器鏡像信息的映射（如果有）。
策略定義中的變量
Kyverno 策略定義可以以快捷方式的形式引用策略定義中的其他字段。這是一種分析和比較值的有用方法，而無需顯式定義它們。為了讓 Kyverno 在清單中引用這些現(xiàn)有值，它使用符號 $(./../key_1/key_2)。這可能看起來很熟悉，因為它本質(zhì)上與 Linux/Unix 系統(tǒng)引用相對路徑的方式相同。
例如下面的策略清單片段：
validationFailureAction: Enforce
rules:
- name: check-tcpSocket
match:
any:
- resources:
kinds:
- Pod
validate:
message: "Port number for the livenessProbe must be less than that of the readinessProbe."
pattern:
spec:
^(containers):
- livenessProbe:
tcpSocket:
port: "$(./../../../readinessProbe/tcpSocket/port)"
readinessProbe:
tcpSocket:
port: "3000"在上面的示例中，對于 Pod 規(guī)范中找到的任何容器字段 readinessProbe.tcpSocket.port 必須為 3000，并且字段 livenessProbe.tcpSocket.port 必須為相同的值。
轉(zhuǎn)義變量
在某些情況下，我們可能希望編寫一個包含變量的規(guī)則，供另一個程序或流程執(zhí)行操作，而不是供 Kyverno 使用。例如，對于 $() 表示法中的變量，可以使用前導(dǎo)反斜杠 (\) 進行轉(zhuǎn)義，并且 Kyverno 不會嘗試替換值。以 JMESPath 表示法編寫的變量也可以使用相同的語法進行轉(zhuǎn)義，例如 \{{ request.object.metadata.name }}。
在下面的策略中，OTEL_RESOURCE_ATTRIBUTES 的值包含對其他環(huán)境變量的引用，這些變量將按字面引用，例如 $(POD_NAMESPACE)。
apiVersion: kyverno.io/v1
kind: Policy
metadata:
name: add-otel-resource-env
namespace: foobar
spec:
background: false
rules:
- name: imbue-pod-spec
match:
any:
- resources:
kinds:
- v1/Pod
mutate:
patchStrategicMerge:
spec:
containers:
- (name): "?*"
env:
- name: NODE_NAME
value: "mutated_name"
- name: POD_IP_ADDRESS
valueFrom:
fieldRef:
fieldPath: status.podIP
- name: POD_NAME
valueFrom:
fieldRef:
fieldPath: metadata.name
- name: POD_NAMESPACE
valueFrom:
fieldRef:
fieldPath: metadata.namespace
- name: POD_SERVICE_ACCOUNT
valueFrom:
fieldRef:
fieldPath: spec.serviceAccountName
- name: OTEL_RESOURCE_ATTRIBUTES
value: >-
k8s.namespace.name=\$(POD_NAMESPACE),
k8s.node.name=\$(NODE_NAME),
k8s.pod.name=\$(POD_NAME),
k8s.pod.primary_ip_address=\$(POD_IP_ADDRESS),
k8s.pod.service_account.name=\$(POD_SERVICE_ACCOUNT),
rule_applied=$(./../../../../../../../../name)比如現(xiàn)在創(chuàng)建一個如下所示的 Pod：
apiVersion: v1
kind: Pod
metadata:
name: test-env-vars
spec:
containers:
- name: test-container
image: busybox
command: ["sh", "-c"]
args:
- while true; do
echo -en '\n';
printenv OTEL_RESOURCE_ATTRIBUTES;
sleep 10;
done;
env:
- name: NODE_NAME
value: "node_name"
- name: POD_NAME
valueFrom:
fieldRef:
fieldPath: metadata.name
- name: POD_NAMESPACE
valueFrom:
fieldRef:
fieldPath: metadata.namespace
- name: POD_IP_ADDRESS
valueFrom:
fieldRef:
fieldPath: status.podIP
restartPolicy: Never該 Pod 相對于 OTEL_RESOURCE_ATTRIBUTES 環(huán)境變量的結(jié)果如下所示：
- name: OTEL_RESOURCE_ATTRIBUTES
value: k8s.namespace.name=$(POD_NAMESPACE), k8s.node.name=$(NODE_NAME), k8s.pod.name=$(POD_NAME),
k8s.pod.primary_ip_address=$(POD_IP_ADDRESS), k8s.pod.service_account.name=$(POD_SERVICE_ACCOUNT),
rule_applied=imbue-pod-spec更多的 Kyverno 策略可以直接查看官方網(wǎng)站：https://kyverno.io/policies，可以在該網(wǎng)站上面根據(jù)策略類型、分類、主題等進行篩選。Kyverno 在靈活、強大和易用之間取得了一個很好的平衡，不需要太多學(xué)習(xí)時間，就能夠提供相當(dāng)方便的功能，官網(wǎng)提供了大量的針對各種場景的樣例，非常值得使用。此外我們還有使用官方提供的 Kyverno Playground 來對你的資源策略進行測試。
