使用 Helm 或 kubectl 安裝和配置 Kyverno 的詳細信息嘉赎。

Kyverno 可以使用 Helm 安裝或直接從 YAML 清單進行部署。 使用這兩種方法中的任何一種時秦驯，都不需要其他步驟來啟動和運行 Kyverno本谜。

注意

從 v1.7.0 開始，Kyverno 遵循與 Kubernetes 項目相同的支持政策讶踪，即 N-2 版本兼容购公。 盡管以前的版本可能有效萌京，但它們未經測試。

兼容矩陣

*由于 Kubernetes 1.23.0-1.23.2 的一個已知問題宏浩，對 1.23 的支持從 1.23.3 開始知残。

使用 Helm 安裝 Kyverno

Kyverno 可以通過 Helm chart 進行安裝——這是生產環(huán)境安裝的推薦方法——可通過 Kyverno 倉庫或 ArtifactHub 得到相關 chart。

為了使用 Helm 安裝 Kyverno比庄，首先添加 Kyverno Helm 倉庫：

helm repo add kyverno https://kyverno.github.io/kyverno/

掃描倉庫以獲取 chart：

helm repo update

（可選）顯示 Kyverno 的所有可用 chart 版本:

helm search repo kyverno -l

根據您希望安裝 Kyverno 的方式橡庞，請參閱下面的高可用性或獨立安裝選項。

要安裝 Kyverno Pod 安全標準策略印蔗，請在安裝 Kyverno 后運行以下 Helm 命令：

helm install kyverno-policies kyverno/kyverno-policies -n kyverno

高可用

官方 Helm chart 是以生產級扒最、高可用的方式安裝 Kyverno 的推薦方法，因為它提供了所有必要的 Kubernetes 資源和配置來滿足生產需求华嘹。通過設置 replicaCount=3吧趣，以下將自動創(chuàng)建并配置為默認值的一部分。這不是一個詳盡的列表耙厚，可能會發(fā)生變化强挫。 對于所有默認值，請參閱 Helm char README 文件薛躬，并牢記發(fā)布分支俯渤。您應該仔細檢查所有可用的 chart 值及其默認值，以確定哪些需要覆蓋（如果有）型宝，以滿足生產環(huán)境的特定需求八匠。

• Kyverno 以3副本方式運行

• PodDisruptionBudget

• Pod 反親和配置

• Kyverno Namespace 排除

注意：Kyverno 不支持兩個副本。 對于高可用性安裝趴酣，只支持三副本梨树。

默認情況下，從 Helm chart 的 2.5.0 版本開始岖寞，將使用配置了不可變標簽 kubernetes.io/metadata.name 的 namespaceSelector 排除 Kyverno 命名空間抡四，通過配置 chart 值可以排除其他命名空間。namespaceSelector 和 objectSelector 都可以用于排除。

另請參閱下面的 Namespace 選擇器部分指巡，尤其是安全性與可操作性部分淑履。

使用 Helm 3.2+ 創(chuàng)建一個命名空間并安裝 Kyverno：

helm install kyverno kyverno/kyverno -n kyverno --create-namespace --set replicaCount=3

對于 3.2 之前的 Helm 版本，需要先創(chuàng)建一個 Namespace藻雪，然后安裝 Kyverno Helm chart秘噪。

kubectl create namespace kyverno
helm install kyverno kyverno/kyverno -n kyverno --create-namespace --set replicaCount=3

從 Kyverno 1.5.0（Helm chart v2.1.0）開始，Kyverno Pod 標準安全策略必須在 Kyverno 安裝后單獨添加：

helm install kyverno-policies kyverno/kyverno-policies -n kyverno

獨立安裝

Kyverno “獨立”安裝適用于試驗阔涉、開發(fā)或測試，或少于3個節(jié)點的小環(huán)境中捷绒。它為 Kyverno 部署配置單個副本瑰排，并省略了許多生產級組件。

使用 Helm 3.2+ 創(chuàng)建一個命名空間并安裝 Kyverno：

helm install kyverno kyverno/kyverno -n kyverno --create-namespace --set replicaCount=1

對于 3.2 之前的 Helm 版本暖侨，需要先創(chuàng)建一個 Namespace椭住，然后安裝 Kyverno Helm chart。

kubectl create namespace kyverno
helm install kyverno kyverno/kyverno -n kyverno --create-namespace --set replicaCount=1

要安裝預發(fā)行版字逗，請將 --devel 開關添加到 Helm京郑。

helm install kyverno kyverno/kyverno -n kyverno --create-namespace --devel

使用 YAML 安裝 Kyverno

Kyverno 也可以使用單個安裝清單進行安裝，但是對于生產安裝葫掉，推薦使用 Helm chart 安裝些举。

此清單路徑將始終指向最新的主分支，并且不保證穩(wěn)定俭厚。

kubectl create -f https://raw.githubusercontent.com/kyverno/kyverno/main/config/install.yaml

您還可以從發(fā)布分支中提取以安裝穩(wěn)定版本户魏，包括候選發(fā)行版本。

kubectl create -f https://raw.githubusercontent.com/kyverno/kyverno/release-1.7/config/release/install.yaml

安全性與可操作性

對于生產環(huán)境挪挤，Kyverno 應該以 HA 模式安裝叼丑。無論 Kyverno 使用哪種安裝方法，了解與任何 webhook 相關的風險以及它如何影響集群操作和安全性都非常重要扛门，尤其是在生產環(huán)境中鸠信。Kyverno 默認（但可配置）以fail closed 模式配置其資源 webhook。這意味著如果 API Server 在嘗試發(fā)送與策略匹配的資源的 AdmissionReview 請求時無法到達 Kyverno论寨，則該請求將失敗星立。例如，存在一個驗證策略葬凳，它檢查所有 Pod 必須以非 root 身份運行贞铣。向 API Server提交了新的 Pod 創(chuàng)建請求，但API Server 無法訪問 Kyverno沮明。 由于無法評估策略辕坝，因此創(chuàng)建 Pod 的請求將失敗。因此荐健，必須注意確保 Kyverno 始終可用酱畅，或者進行適當配置以排除某些關鍵命名空間琳袄，特別是 Kyverno 的命名空間，以確保它可以接收這些 API 請求纺酸。 無論選擇哪個選項窖逗，都需要在默認安全性和可操作性之間進行權衡。

如果不排除 Kyverno 命名空間餐蔬，以下組合可能會導致集群無法運行：

• 在 fail closed 模式下（默認配置）碎紊，Pod 匹配到至少一個 Kyverno 規(guī)則。

• 至少沒有為 Kyverno 命名空間配置命名空間排除項樊诺，可能還有其他關鍵系統(tǒng)命名空間（例如仗考，kube-system）。Helm char 2.5.0 版本中不是默認配置词爬。

• 所有 Kyverno Pod 由于集群完全中斷或節(jié)點擴展不當（例如秃嗜，作為自動擴展操作的一部分而在沒有首先封鎖和排空 Pod 的情況下，云 PaaS 銷毀節(jié)點組中的太多節(jié)點）而變得不可用顿膨。

如果出現這種情況锅锨，恢復的唯一方法是手動刪除 ValidatingWebhookConfigurations，從而允許新的 Kyverno Pod 啟動恋沃。 故障排除部分提供了恢復步驟必搞。

注意
Kubernetes 不會將 ValidatingWebhookConfiguration 或 MutatingWebhookConfiguration 對象發(fā)送到準入控制器，因此無法使用 Kyverno 策略來驗證或改變這些對象囊咏。

相比之下顾画，這些可操作性問題可以通過做出一些安全讓步來緩解。 具體來說匆笤，通過在安裝過程中排除 Kyverno 和其他系統(tǒng)命名空間研侣，如果出現上述故障情況，Kyverno 應該能夠自行恢復而無需人工干預炮捧。這是 Helm chart 2.5.0 版的默認行為庶诡。但是，配置這些排除項意味著后續(xù)策略將無法對發(fā)往這些命名空間的資源采取行動咆课，因為 API Server 已被告知不要為它們發(fā)送 AdmissionReview 請求末誓。因此，為這些命名空間提供控制取決于集群管理員的操作书蚪，例如喇澡，Kubernetes RBAC 可限制哪些人或哪些操作可以在這些被排查的命名空間中執(zhí)行。

注意
命名空間和/或命名空間中的對象可以通過多種方式排除殊校，包括命名空間選擇器和對象選擇器晴玖。 Helm chart 為兩者提供了選項，但默認情況下，Kyverno 命名空間將被排除在外呕屎。

注意
使用 objectSelector 時让簿，如果用戶發(fā)現 webhook 的配置方式，他們可能會通過配置 webhook 的相同標簽鍵/值來欺騙 webhook秀睛，從而允許資源繞過策略檢測尔当。 因此，建議使用使用 kubernetes.io/metadata.name 不可變標簽的 namespaceSelector蹂安。

因此椭迎，這些選擇及其影響是：

• 在安裝過程時不排除系統(tǒng)命名空間，包括 Kyverno 的（非默認）田盈，這會使默認情況下更加安全畜号，但在某些中斷情況下可能需要手動恢復。這是默認行為缠黍，除非被覆蓋弄兜。

• 在安裝過程中排除系統(tǒng)命名空間（默認）可以更輕松地恢復集群药蜻，但可能需要其他方法來保護這些命名空間瓷式，例如使用 Kubernetes RBAC。

您應該根據您的風險規(guī)避语泽、需求和操作實踐選擇最佳選項贸典。

注意
如果您選擇不排除 Kyverno 或系統(tǒng)命名空間/對象并打算用策略覆蓋它們，您可能需要修改 ConfigMap 中的 Kyverno resourceFilters 配置以刪除這些條目踱卵。

自定義安裝Kyverno

下圖顯示了典型的 Kyverno 安裝：

[圖片上傳失敗...(image-1da32d-1663730295834)]

如果您希望自定義 Kyverno 的安裝以使證書由內部或受信任的 CA 簽名廊驼，或者以其他方式了解組件如何協(xié)同工作，請遵循以下指南惋砂。

安裝特定版本

要安裝特定版本妒挎，請下載 install.yaml并修改鏡像tag：

例如，將鏡像 tag 從 latest 更改為特定標簽 v1.3.0西饵。

spec:
  containers:
    - name: kyverno
      # image: ghcr.io/kyverno/kyverno:latest
      image: ghcr.io/kyverno/kyverno:v1.3.0

要在特定命名空間中安裝酝掩，請將命名空間“kyverno”替換為您的命名空間。

例如：

apiVersion: v1
kind: Namespace
metadata:
  name: <namespace>

apiVersion: v1
kind: Service
metadata:
  labels:
    app: kyverno
  name: kyverno-svc
  namespace: <namespace>

以及其他提到命名空間的地方（ServiceAccount眷柔、ClusterRoles期虾、ClusterRoleBindings、ConfigMaps驯嘱、Service镶苞、Deployment）。

ConfigMap Flags

以下標志用于控制 Kyverno 的行為鞠评，必須在 Kyverno ConfigMap 中設置茂蚓。

1. excludeGroupRole：excludeGroupRole 字符串，以逗號分隔的 group role。它將從用戶請求中排除所有組角色煌贴。默認使用 system:serviceaccounts:kube-system,system:nodes,system:kube-scheduler御板。

2. excludeUsername：excludeUsername 字符串，以逗號分隔的 kubernetes 用戶名牛郑。在生成請求中怠肋，如果用戶在生成策略中啟用同步，則只有 kyverno 可以更新/刪除生成的資源淹朋，但管理員可以排除特定用戶名笙各，使其有權刪除/更新生成的資源。

3. resourceFilters：不由 admission webhook 策略評估的Kubernetes 資源础芍，格式為“[kind,namespace,name]”杈抢。 例如 –filterKind “[Deployment, kyverno, kyverno]” –filterKind “[Deployment, kyverno, kyverno],[Events, *, *]”。

4. generateSuccessEvents：指定是否 (true/false) 生成成功事件仑性。 默認設置為“false”惶楼。

5. webhooks：指定要在 Kyverno 管理的 webhook 中配置排除的命名空間或對象。

Container Flags

以下標志也可用于控制 Kyverno 的高級行為诊杆，并且必須以參數的形式在 kyverno 主容器上設置歼捐。

1. -v：設置 Kyverno 日志輸出的詳細級別。 取一個從 1 到 6 的整數晨汹，其中 6 是最詳細的豹储。 級別 4 顯示變量替換消息。

2. profile：將此標志設置為“true”將啟用分析淘这。

3. profilePort：指定端口以啟用分析剥扣，默認為 6060。

4. metricsPort：指定暴露 prometheus 指標的端口铝穷，默認為 8000 端口钠怯。

5. genWorkers：并行處理生成策略的 worker 數量，默認是10曙聂。

6. disableMetrics：指定是否 (true/false) 啟用公開指標晦炊。 默認為“false”。

7. backgroundScan：后臺處理的時間間隔（如 30s筹陵、15m刽锤、12h）。 默認為 1h朦佩。

8. imagePullSecrets：指定 image registry 訪問憑證的 secret 資源名稱并思。

9. allowInsecureRegistry: 允許 Kyverno 使用不安全的 image registry（即繞過證書檢查），使用 verifyImages 規(guī)則或來自 image registry 的變量语稠。僅用于測試目的宋彼。 不得用于生產環(huán)境弄砍。

10. autoUpdateWebhooks: 將此標志設置為“false”以禁用 webhook 的自動配置。 禁用此功能后输涕，Kyverno 會創(chuàng)建一個默認的 webhook 配置（匹配所有類型的資源）音婶，因此，通過 configmap 的 webhook 配置將被忽略莱坎。 但是衣式，用戶仍然可以通過手動修補 webhook 資源來修改它。 默認為“true”檐什。

11. imageSignatureRepository：指定鏡像簽名的備用存儲庫碴卧。 可以根據規(guī)則覆蓋以驗證 Images.Repository。

12. webhookRegistrationTimeout：指定 Kyverno 嘗試向 API Server 注冊 webhook 的時間長度乃正。 默認為 120 秒住册。

13. clientRateLimitQPS：配置從 Kyverno 到控制平面的最大 QPS。 如果為零瓮具，則使用客戶端默認值荧飞。 示例：20

14. clientRateLimitBurst：配置限制的最大突發(fā)流量。 如果為零名党，則使用客戶端默認值叹阔。 示例：50

15. webhookTimeout：指定 webhook 的超時時間。 超時后兑巾，根據失敗策略条获，Webhook 調用將被忽略或 API 調用失敗忠荞。超時值必須在 1 到 30 秒之間蒋歌，默認為 10 秒。

16. autogenInternals：Kyverno 1.7.0 中新增的委煤。此標志激活（當前為測試版）自動生成規(guī)則計算，以不寫入 Kyverno 策略的 .spec 字段。 這是正在建設中咒锻，行為將在未來發(fā)生變化比规。 默認設置為false。 設置為 true 以激活此能力讥邻。

訪問策略報告

安裝 Kyverno 時迫靖，會生成一個 ClusterRole kyverno:admin-policyreport，它有權對 policyreport 和 clusterpolicyreport 資源執(zhí)行所有操作兴使。要授予對命名空間管理員權限系宜，請配置以下 YAML 文件，然后將其應用于集群发魄。

• 將 metadata.namespace 替換為管理員的命名空間

• 配置 subjects 字段盹牧，綁定管理員角色到 ClusterRole policyviolation

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: policyviolation
  # change namespace below to create rolebinding for the namespace admin
  namespace: default
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: kyverno:admin-policyreport
subjects:
# configure below to access policy violation for the namespace admin
- kind: ServiceAccount
  name: default
  namespace: default
# - apiGroup: rbac.authorization.k8s.io
#   kind: User
#   name:
# - apiGroup: rbac.authorization.k8s.io
#   kind: Group
#   name:

Webhooks

從 Kyverno 1.5.0 版本開始俩垃，通過配置策略來實現對 mutatingWebhookConfiguration 和 validatingWebhookConfiguration 資源的動態(tài)注冊和管理。在 1.5.0 之前汰寓，Kyverno 使用通配符 webhook口柳，允許它接收所有資源的準入請求。借助 webhook 自動配置功能有滑，Kyverno 現在只接收選定資源的準入請求跃闹，從而防止將不必要的準入請求轉發(fā)給 Kyverno。

另外毛好，failurePolicy 和 webhookTimeoutSeconds 策略配置選項允許對 webhook 設置進行精細控制辣卒。默認情況下，策略會被配置為“fail-closed”（即如果 webhook 調用出現意外錯誤或超時睛榄，準入請求將失斎倜！），除非 failurePolicy 被設置為 Ignore场靴。

這個特性在 1.5.0+ 默認啟用啡莉，可以通過--autoUpdateWebhooks=false 標志來關閉。如果禁用旨剥，Kyverno 會創(chuàng)建默認的 webhook 配置來轉發(fā)所有資源的準入請求咧欣，并將 FailurePolicy 設置為 Ignore。

spec.failurePolicy 和 spec.webhookTimeoutSeconds 及策略配置字段允許自動聚合并用于注冊所需的 webhook 配置集的每個策略設置轨帜。

在 1.5.0 之前魄咕，默認情況下，Kyverno webhook 將處理所有命名空間的所有 API Server請求蚌父，并且使用下面討論的資源過濾器和命名空間選擇器過濾策略應用程序哮兰。

資源過濾器

資源過濾器是一種指示 Kyverno 忽略 API Server發(fā)送的 AdmissionReview 請求的方法。這與配置 webhook 的能力不同苟弛『戎停可以通過在 Namespace kyverno 中添加 ConfigMap 并在 data.resourceFilters 下指定要過濾的資源來過濾策略應該忽略的 Kubernetes 種類。

Namespace 過濾器

apiVersion: v1
data:
  resourceFilters: '[Event,*,*][*,kube-system,*][*,kube-public,*][*,kube-node-lease,*][Node,*,*][APIService,*,*][TokenReview,*,*][SubjectAccessReview,*,*][SelfSubjectAccessReview,*,*][*,kyverno,*][Binding,*,*][ReplicaSet,*,*][ReportChangeRequest,*,*][ClusterReportChangeRequest,*,*]'
  webhooks: '[{"namespaceSelector":{"matchExpressions":[{"key":"kubernetes.io/metadata.name","operator":"NotIn","values":["kyverno"]}]}}]'
kind: ConfigMap
metadata:
  name: kyverno
  namespace: kyverno

升級Kyverno

升級 Kyverno 就像應用新的 YAML 清單一樣簡單膏秫，或者根據安裝方式使用 Helm右遭。

使用 YAML 清單升級 Kyverno

在現有安裝上應用新清單。

kubectl apply -f https://raw.githubusercontent.com/kyverno/kyverno/main/config/install.yaml

使用 Helm 升級 Kyverno

Kyverno 可以像任何其他 Helm Chat一樣升級缤削。

掃描您的 Helm 存儲庫以獲取更新的 Chart窘哈。

helm repo update

顯示可用的 Kyverno chart版本。 要查看預發(fā)布chart亭敢，請將 --devel 標志添加到 helm 命令滚婉。

helm search repo kyverno

運行升級命令以選擇目標版本。

helm upgrade kyverno kyverno/kyverno --namespace kyverno --version <version_number>

注意
從 1.4.2 到 1.4.3（Helm chart >=v2.0.2 <v2.1.0）之間的版本升級到 Kyverno 1.5.0+（Helm chart v2.1.0）需要額外的步驟吨拗。 刪除 CRD 的步驟將導致所有 Kyverno 策略被刪除满哪，因此必須對 Helm 未添加的策略進行備份婿斥。

以下是將 Kyverno 從 1.4.3 升級到 1.5.0 的步驟。 升級到 1.5.0+ 需要首先刪除舊的 CRDs 圖表哨鸭。

首先備份所有非 Helm 添加的集群策略：

kubectl get clusterpolicy -l app.kubernetes.io/managed-by!=Helm -A -o yaml > kyverno-policies.yaml

執(zhí)行升級：

helm uninstall kyverno --namespace kyverno
helm uninstall kyverno-crds --namespace kyverno
helm install kyverno kyverno/kyverno --namespace kyverno --version <version_number>

恢復 Kyverno 集群策略：

kubectl apply -f kyverno-policies.yaml

卸載 Kyverno

要卸載 Kyverno民宿，請使用原始 YAML 清單或 Helm。 Kyverno Deployment像鸡、RBAC 資源和所有 CRD 將被刪除活鹰，包括任何報告。

選項 1 - 使用 YAML 清單卸載 Kyverno

kubectl delete -f https://raw.githubusercontent.com/kyverno/kyverno/main/config/install.yaml

選項 2 - 使用 Helm 卸載 Kyverno

helm uninstall kyverno kyverno/kyverno --namespace kyverno

清理 Webhook 配置

默認情況下只估，Kyverno 將在終止時嘗試清理其所有 webhook 配置志群。 但如果首先刪除其 RBAC 資源，它將失去正確執(zhí)行此操作的權限蛔钙。

無論選擇哪種卸載方法锌云，最后一步（根據譯者實踐，建議第一步就刪除 webhook吁脱，否則可能導致 API Server 請求超時）都需要手動刪除 webhook桑涎。 使用以下命令刪除這些 webhook 配置。

kubectl delete mutatingwebhookconfigurations kyverno-policy-mutating-webhook-cfg kyverno-resource-mutating-webhook-cfg kyverno-verify-mutating-webhook-cfg

kubectl delete validatingwebhookconfigurations kyverno-policy-validating-webhook-cfg kyverno-resource-validating-webhook-cfg