“本帖子是基于Kyverno官方文档中快速入门的内容，为帮助理解而进行的韩语翻译和整理。”
>
https://kyverno.io/blog/2023/11/16/kyverno-1.11-released/
Kyverno策略和规则类型介绍
本节提供了一个快速安装和运行Kyverno的指南，并演示了Kyverno的一些核心功能。我们准备了侧重于验证(Validation)、变异(Mutation)和生成(Generation)的指南，您可以选择最适合您用例的项目进行操作。
注意：这些指南是为概念验证(PoC)或实践而设计的，不建议用于生产环境。有关生产环境安装的详细信息，请参阅[安装页面]。
首先，使用最新发布清单安装Kyverno。
kubectl create -f https://github.com/kyverno/kyverno/releases/latest/download/install.yaml接下来，选择您感兴趣的快速入门指南。或者，您也可以从头开始按顺序进行。
1. 验证资源 (Validate Resources)
在验证指南中，我们将探讨一个简单的策略示例，该策略要求所有Pod必须包含一个名为“team”的标签。验证是策略最常见的用例，它充当一个决定“是”或“否”的决策过程。符合策略的资源将被允许通过（“是，允许”），而不符合策略的资源可能会被拒绝通过（“否，不允许”）。
验证策略的另一个效果是生成
策略报告(Policy Reports)
。策略报告是Kyverno创建和管理的自定义资源(CRD)，它以用户友好的方式显示已允许资源的策略决策结果。
将以下策略添加到您的集群中。它包含一个单一的验证规则，要求所有Pod都必须有一个“team”标签。（Kyverno除了验证之外，还支持多种规则类型，例如变异、生成、清理和镜像配置检查。）failureAction字段设置为Enforce，这将阻止不符合要求的Pod。如果使用默认值Audit，则只会报告违规行为，而不会阻止请求。
YAML
kubectl create -f- << EOF
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
name: require-labels
spec:
# 创建一个名为check-team的规则，当发生与Pod相关的匹配时执行检查
rules:
- name: check-team
match:
any:
- resources:
kinds:
- Pod
# 必须配置名为team的标签。不能缺少。
validate:
failureAction: Enforce
message: "label 'team' is required"
pattern:
metadata:
labels:
team: "?*"
EOF尝试创建一个没有必需标签的Deployment。
kubectl create deployment nginx --image=nginx应该会发生以下错误：
error: failed to create deployment: admission webhook "validate.kyverno.svc-fail" denied the request:
resource Deployment/default/nginx was blocked due to the following policies:
require-labels:
autogen-check-team: 'validation error: label ''team'' is
required. Rule autogen-check-team failed at path /spec/template/metadata/labels/team/'除了返回错误之外，Kyverno还在同一命名空间中生成一个包含该信息的事件(Event)。
注意：Kyverno可能被配置为排除kube-system或kyverno等系统命名空间。测试时请使用自定义命名空间或default命名空间。
请注意，策略针对的是Pod，但您刚刚创建的Deployment被阻止了。这得益于Kyverno的规则自动生成(rule auto-generation)功能。Kyverno智能地将专门为Pod编写的策略应用于所有标准的Kubernetes Pod控制器，包括Deployment。
现在，尝试创建一个包含必需标签的Pod。
kubectl run nginx --image nginx --labels team=backend此Pod配置符合策略，因此允许其创建。Pod创建后，等待几秒钟，然后检查Kyverno执行的其他操作。运行以下命令以查看Kyverno刚刚生成的策略报告。
kubectl get policyreport -o wide您可以看到策略报告中“PASS”列的结果为1。这是因为您刚刚创建的Pod通过了策略。
NAME KIND NAME PASS FAIL WARN ERROR SKIP AGE
3f9d6279-445b-403d-a255-2a0a8da419a8 Pod nginx 1 0 0 0 0 4s
72a484fd-29a8-4126-ade6-ade1c4aba275 ReplicaSet my-backstage-84ff474f85 0 1 0 0 0 2m7s
7492fb75-0003-4d6d-9ce0-fcf52c933f0c Pod my-backstage-84ff474f85-8777r 0 1 0 0 0 2m7s
757ae125-e628-46b7-ab20-6849a831baae Deployment my-backstage 0 1 0 0 0 2m7s删除您刚刚创建的策略以进行清理。
kubectl delete clusterpolicy require-labels恭喜！您已成功在Kubernetes集群中实施了验证策略。
2. 变异资源 (Mutate Resources)
变异是指在资源被集群接纳之前，更改或“转换”资源的能力。变异规则与验证规则类似，选择资源（如Pod或ConfigMap）并定义其所需状态。
将以下变异策略添加到您的集群中。此策略会为所有新的Pod添加一个“team”标签，并将其值设置为“bravo”，但仅当该Pod尚未分配此标签时才执行。+(team)表示法使用Kyverno锚点来定义当标签键不存在时要执行的操作。
kubectl create -f- << EOF
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
name: add-labels
spec:
# 与之前的规则相同，当kind匹配Pod时执行操作
rules:
- name: add-team
match:
any:
- resources:
kinds:
- Pod
# 这次，执行一个变异操作，将team: bravo信息合并到标签中
mutate:
patchStrategicMerge:
metadata:
labels:
+(team): bravo
EOF现在，尝试创建一个没有定义标签的新Pod。
kubectl run redis --image redis检查已创建Pod的标签。
# kubectl get pod redis --show-labels
NAME READY STATUS RESTARTS AGE LABELS
redis 0/1 ContainerCreating 0 7s run=redis,team=bravo您可以看到Kyverno已添加了team=bravo标签。现在，尝试创建一个已经定义了“team”标签的Pod。
kubectl run newredis --image redis -l team=alpha如果您再次检查此Pod的标签，您会发现Kyverno没有用策略中定义的值覆盖它，因为该标签已经存在。因此，合并功能不会覆盖现有标签。
# kubectl get pod --show-labels newredis
NAME READY STATUS RESTARTS AGE LABELS
newredis 1/1 Running 0 44s team=alpha完成操作后，删除策略。
kubectl delete clusterpolicy add-labels3. 生成资源 (Generate Resources)
Kyverno具有根据策略中存储的定义生成新的Kubernetes资源的能力。生成功能非常强大和灵活，不仅提供初始创建，还提供持续同步已生成资源的能力。
在本指南中，我们将探讨一个在新命名空间创建时自动生成镜像拉取密钥(image pull secret)的策略。首先，创建一个模拟真实密钥的测试密钥。
kubectl -n default create secret docker-registry regcred
--docker-server=myinternalreg.corp.com
--docker-username=john.doe
--docker-password=Passw0rd123!
--docker-email=john.doe@corp.com默认情况下，Kyverno配置为最小权限，无法访问像密钥这样的敏感资源。您必须通过集群角色聚合(cluster role aggregation)授予权限。
kubectl apply -f- << EOF
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: kyverno:secrets:view
labels:
rbac.kyverno.io/aggregate-to-admission-controller: "true"
rbac.kyverno.io/aggregate-to-reports-controller: "true"
rbac.kyverno.io/aggregate-to-background-controller: "true"
rules:
- apiGroups:
- ''
resources:
- secrets
verbs:
- get
- list
- watch
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: kyverno:secrets:manage
labels:
rbac.kyverno.io/aggregate-to-background-controller: "true"
rules:
- apiGroups:
- ''
resources:
- secrets
verbs:
- create
- update
- delete
EOF现在，创建以下Kyverno策略。sync-secrets策略会检测新创建的命名空间，并将您刚刚创建的密钥复制到该命名空间中。
kubectl create -f- << EOF
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
name: sync-secrets
spec:
# 这次，当检测到命名空间创建时执行操作
rules:
- name: sync-image-pull-secret
match:
any:
- resources:
kinds:
- Namespace
# 包含在请求的NS中创建Secret的规则，此Secret从default复制而来
generate:
apiVersion: v1
kind: Secret
name: regcred
namespace: "{{request.object.metadata.name}}"
synchronize: true
clone:
namespace: default
name: regcred
EOF为测试创建一个新的命名空间。
kubectl create ns mytestns检查新命名空间中是否存在regcred密钥。
kubectl -n mytestns get secret您可以看到Kyverno使用default命名空间中的源密钥作为模板创建了regcred密钥。如果您修改原始密钥，Kyverno将把更改同步到所有生成它的地方。
最后，删除策略以进行清理。
kubectl delete clusterpolicy sync-secrets
发表回复