Kyverno安装

作者: 王勇1024 | 来源:发表于2022-09-21 11:38 被阅读0次

使用 Helm 或 kubectl 安装和配置 Kyverno 的详细信息。

Kyverno 可以使用 Helm 安装或直接从 YAML 清单进行部署。使用这两种方法中的任何一种时，都不需要其他步骤来启动和运行 Kyverno。

注意

从 v1.7.0 开始，Kyverno 遵循与 Kubernetes 项目相同的支持政策，即 N-2 版本兼容。尽管以前的版本可能有效，但它们未经测试。

兼容矩阵

Kyverno Version	Kubernetes Min	Kubernetes Max
1.4.x	1.16	1.21
1.5.x	1.16	1.21
1.6.x	1.16	1.23
1.7.x	1.21	1.23

*由于 Kubernetes 1.23.0-1.23.2 的一个已知问题，对 1.23 的支持从 1.23.3 开始。

使用 Helm 安装 Kyverno

Kyverno 可以通过 Helm chart 进行安装——这是生产环境安装的推荐方法——可通过 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，以下将自动创建并配置为默认值的一部分。这不是一个详尽的列表，可能会发生变化。对于所有默认值，请参阅 Helm char README 文件，并牢记发布分支。您应该仔细检查所有可用的 chart 值及其默认值，以确定哪些需要覆盖（如果有），以满足生产环境的特定需求。

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+ 创建一个命名空间并安装 Kyverno：

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

对于 3.2 之前的 Helm 版本，需要先创建一个 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 “独立”安装适用于试验、开发或测试，或少于3个节点的小环境中。它为 Kyverno 部署配置单个副本，并省略了许多生产级组件。

使用 Helm 3.2+ 创建一个命名空间并安装 Kyverno：

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

对于 3.2 之前的 Helm 版本，需要先创建一个 Namespace，然后安装 Kyverno Helm chart。

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

要安装预发行版，请将 --devel 开关添加到 Helm。

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

使用 YAML 安装 Kyverno

Kyverno 也可以使用单个安装清单进行安装，但是对于生产安装，推荐使用 Helm chart 安装。

此清单路径将始终指向最新的主分支，并且不保证稳定。

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

您还可以从发布分支中提取以安装稳定版本，包括候选发行版本。

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

安全性与可操作性

对于生产环境，Kyverno 应该以 HA 模式安装。无论 Kyverno 使用哪种安装方法，了解与任何 webhook 相关的风险以及它如何影响集群操作和安全性都非常重要，尤其是在生产环境中。Kyverno 默认（但可配置）以fail closed 模式配置其资源 webhook。这意味着如果 API Server 在尝试发送与策略匹配的资源的 AdmissionReview 请求时无法到达 Kyverno，则该请求将失败。例如，存在一个验证策略，它检查所有 Pod 必须以非 root 身份运行。向 API Server提交了新的 Pod 创建请求，但API Server 无法访问 Kyverno。由于无法评估策略，因此创建 Pod 的请求将失败。因此，必须注意确保 Kyverno 始终可用，或者进行适当配置以排除某些关键命名空间，特别是 Kyverno 的命名空间，以确保它可以接收这些 API 请求。无论选择哪个选项，都需要在默认安全性和可操作性之间进行权衡。

如果不排除 Kyverno 命名空间，以下组合可能会导致集群无法运行：

在 fail closed 模式下（默认配置），Pod 匹配到至少一个 Kyverno 规则。
至少没有为 Kyverno 命名空间配置命名空间排除项，可能还有其他关键系统命名空间（例如，kube-system）。Helm char 2.5.0 版本中不是默认配置。
所有 Kyverno Pod 由于集群完全中断或节点扩展不当（例如，作为自动扩展操作的一部分而在没有首先封锁和排空 Pod 的情况下，云 PaaS 销毁节点组中的太多节点）而变得不可用。

如果出现这种情况，恢复的唯一方法是手动删除 ValidatingWebhookConfigurations，从而允许新的 Kyverno Pod 启动。故障排除部分提供了恢复步骤。

注意
Kubernetes 不会将 ValidatingWebhookConfiguration 或 MutatingWebhookConfiguration 对象发送到准入控制器，因此无法使用 Kyverno 策略来验证或改变这些对象。

相比之下，这些可操作性问题可以通过做出一些安全让步来缓解。具体来说，通过在安装过程中排除 Kyverno 和其他系统命名空间，如果出现上述故障情况，Kyverno 应该能够自行恢复而无需人工干预。这是 Helm chart 2.5.0 版的默认行为。但是，配置这些排除项意味着后续策略将无法对发往这些命名空间的资源采取行动，因为 API Server 已被告知不要为它们发送 AdmissionReview 请求。因此，为这些命名空间提供控制取决于集群管理员的操作，例如，Kubernetes RBAC 可限制哪些人或哪些操作可以在这些被排查的命名空间中执行。

注意
命名空间和/或命名空间中的对象可以通过多种方式排除，包括命名空间选择器和对象选择器。 Helm chart 为两者提供了选项，但默认情况下，Kyverno 命名空间将被排除在外。

注意
使用 objectSelector 时，如果用户发现 webhook 的配置方式，他们可能会通过配置 webhook 的相同标签键/值来欺骗 webhook，从而允许资源绕过策略检测。因此，建议使用使用 kubernetes.io/metadata.name 不可变标签的 namespaceSelector。

因此，这些选择及其影响是：

在安装过程时不排除系统命名空间，包括 Kyverno 的（非默认），这会使默认情况下更加安全，但在某些中断情况下可能需要手动恢复。这是默认行为，除非被覆盖。
在安装过程中排除系统命名空间（默认）可以更轻松地恢复集群，但可能需要其他方法来保护这些命名空间，例如使用 Kubernetes RBAC。

您应该根据您的风险规避、需求和操作实践选择最佳选项。

注意
如果您选择不排除 Kyverno 或系统命名空间/对象并打算用策略覆盖它们，您可能需要修改 ConfigMap 中的 Kyverno resourceFilters 配置以删除这些条目。

自定义安装Kyverno

下图显示了典型的 Kyverno 安装：

[图片上传失败...(image-1da32d-1663730295834)]

如果您希望自定义 Kyverno 的安装以使证书由内部或受信任的 CA 签名，或者以其他方式了解组件如何协同工作，请遵循以下指南。

安装特定版本

要安装特定版本，请下载 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 中设置。

excludeGroupRole：excludeGroupRole 字符串，以逗号分隔的 group role。它将从用户请求中排除所有组角色。默认使用 system:serviceaccounts:kube-system,system:nodes,system:kube-scheduler。
excludeUsername：excludeUsername 字符串，以逗号分隔的 kubernetes 用户名。在生成请求中，如果用户在生成策略中启用同步，则只有 kyverno 可以更新/删除生成的资源，但管理员可以排除特定用户名，使其有权删除/更新生成的资源。
resourceFilters：不由 admission webhook 策略评估的Kubernetes 资源，格式为“[kind,namespace,name]”。例如 –filterKind “[Deployment, kyverno, kyverno]” –filterKind “[Deployment, kyverno, kyverno],[Events, *, *]”。
generateSuccessEvents：指定是否 (true/false) 生成成功事件。默认设置为“false”。
webhooks：指定要在 Kyverno 管理的 webhook 中配置排除的命名空间或对象。

Container Flags

以下标志也可用于控制 Kyverno 的高级行为，并且必须以参数的形式在 kyverno 主容器上设置。

-v：设置 Kyverno 日志输出的详细级别。取一个从 1 到 6 的整数，其中 6 是最详细的。级别 4 显示变量替换消息。
profile：将此标志设置为“true”将启用分析。
profilePort：指定端口以启用分析，默认为 6060。
metricsPort：指定暴露 prometheus 指标的端口，默认为 8000 端口。
genWorkers：并行处理生成策略的 worker 数量，默认是10。
disableMetrics：指定是否 (true/false) 启用公开指标。默认为“false”。
backgroundScan：后台处理的时间间隔（如 30s、15m、12h）。默认为 1h。
imagePullSecrets：指定 image registry 访问凭证的 secret 资源名称。
allowInsecureRegistry: 允许 Kyverno 使用不安全的 image registry（即绕过证书检查），使用 verifyImages 规则或来自 image registry 的变量。仅用于测试目的。不得用于生产环境。
autoUpdateWebhooks: 将此标志设置为“false”以禁用 webhook 的自动配置。禁用此功能后，Kyverno 会创建一个默认的 webhook 配置（匹配所有类型的资源），因此，通过 configmap 的 webhook 配置将被忽略。但是，用户仍然可以通过手动修补 webhook 资源来修改它。默认为“true”。
imageSignatureRepository：指定镜像签名的备用存储库。可以根据规则覆盖以验证 Images.Repository。
webhookRegistrationTimeout：指定 Kyverno 尝试向 API Server 注册 webhook 的时间长度。默认为 120 秒。
clientRateLimitQPS：配置从 Kyverno 到控制平面的最大 QPS。如果为零，则使用客户端默认值。示例：20
clientRateLimitBurst：配置限制的最大突发流量。如果为零，则使用客户端默认值。示例：50
webhookTimeout：指定 webhook 的超时时间。超时后，根据失败策略，Webhook 调用将被忽略或 API 调用失败。超时值必须在 1 到 30 秒之间，默认为 10 秒。
autogenInternals：Kyverno 1.7.0 中新增的。此标志激活（当前为测试版）自动生成规则计算，以不写入 Kyverno 策略的 .spec 字段。这是正在建设中，行为将在未来发生变化。默认设置为false。设置为 true 以激活此能力。

访问策略报告

安装 Kyverno 时，会生成一个 ClusterRole kyverno:admin-policyreport，它有权对 policyreport 和 clusterpolicyreport 资源执行所有操作。要授予对命名空间管理员权限，请配置以下 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 资源的动态注册和管理。在 1.5.0 之前，Kyverno 使用通配符 webhook，允许它接收所有资源的准入请求。借助 webhook 自动配置功能，Kyverno 现在只接收选定资源的准入请求，从而防止将不必要的准入请求转发给 Kyverno。

另外，failurePolicy 和 webhookTimeoutSeconds 策略配置选项允许对 webhook 设置进行精细控制。默认情况下，策略会被配置为“fail-closed”（即如果 webhook 调用出现意外错误或超时，准入请求将失败），除非 failurePolicy 被设置为 Ignore。

这个特性在 1.5.0+ 默认启用，可以通过--autoUpdateWebhooks=false 标志来关闭。如果禁用，Kyverno 会创建默认的 webhook 配置来转发所有资源的准入请求，并将 FailurePolicy 设置为 Ignore。

spec.failurePolicy 和 spec.webhookTimeoutSeconds 及策略配置字段允许自动聚合并用于注册所需的 webhook 配置集的每个策略设置。

在 1.5.0 之前，默认情况下，Kyverno webhook 将处理所有命名空间的所有 API Server请求，并且使用下面讨论的资源过滤器和命名空间选择器过滤策略应用程序。

资源过滤器

资源过滤器是一种指示 Kyverno 忽略 API Server发送的 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版本。要查看预发布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

执行升级：

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 资源，它将失去正确执行此操作的权限。

无论选择哪种卸载方法，最后一步（根据译者实践，建议第一步就删除 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