Kubernetes ポリシー管理エンジン - Kyverno

Kyverno は Nirmata のオープンソース プロジェクトであり、後に CNCF に寄贈されました。 Kyverno は検証および変更機能を備えた Kubernetes ポリシー エンジンですが、リソースを生成したり、API オブジェクトをクエリする機能を追加したりする機能も備えています。 Kyverno はもともと Kubernetes 用に作成されたもので、オブジェクト生成機能に加えて、ポリシーを記述するための専用言語を必要としません。

同様に、Kyverno は Kubernetes クラスター内で動的アドミッション コントローラーとして実行されます。 Kyverno は、kube-apiserver から検証および変更のアドミッション Webhook HTTP コールバックを受信し、一致するポリシーを適用して、アドミッション ポリシーの適用またはリクエストの拒否の結果を返します。 Kyverno ポリシーは、リソースの種類、名前、ラベル セレクターを使用してリソースを照合し、名前にワイルドカードをサポートします。

ポリシーの適用は Kubernetes イベントを通じてキャプチャされ、Kyverno は既存のリソースに対するポリシー違反も報告します。次の図は、Kyverno の全体的なアーキテクチャを示しています。

キベルノアーキテクチャ

Kyverno の高可用性インストールは複数のレプリカを実行することで実現でき、Kyverno の各レプリカには異なる機能を実行する複数のコントローラーが含まれます。 Webhook は Kubernetes APIServer からの AdmissionReview リクエストを処理し、その Monitor コンポーネントは必要な構成を作成および管理します。 PolicyController はポリシー リソースを監視し、構成されたスキャン間隔に基づいてバックグラウンド スキャンを開始し、GenerateController は生成されたリソースのライフサイクルを管理します。

インストール

まず、Kubernetes クラスターのバージョンが v1.14 より上であることを確認する必要があります。インストールするバージョンも Kubernetes のバージョンに関連しています。

互換性のあるバージョン

すでにバージョン v1.28.x がインストールされていますので、最新バージョン 1.11.4 をインストールすることを選択してください。

最新バージョンのリソース リストから Kyverno を直接インストールすることもできます。次のコマンドを実行するだけです。

 ➜ 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.

インストールが完了すると、kube-kyverno 名前空間が作成され、関連する 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

インストールが完了すると、いくつかの validatingwebhookconfiguration オブジェクトと mutatingwebhookconfigurations オブジェクトが作成されることがわかります。

戦略とルール

Kyverno を使用するということは、実際には戦略とルールを適用することです。 Kyverno 戦略はルールの集合です。各ルールは、match ステートメント、オプションの exclude ステートメント、および validate、mutate、generate、または verifyImages ステートメントのいずれかで構成されます。各ルールには、validate、mutate、generate、または verifyImages サブステートメントを 1 つだけ含めることができます。

キベルノ戦略

ポリシーは、クラスター全体のリソース (ClusterPolicy) または名前空間レベルのリソース (Policy) として定義できます。

• ポリシーは、定義されている名前空間内のリソースにのみ適用されます。
• ClusterPolicy は、すべての名前空間にわたるリソースを一致させるために適用されます。

ポリシー定義

ポリシーを記述するということは、実際には Policy または ClusterPolicy オブジェクトを定義することです。

リソースを確認する

検証ルールは、基本的に私たちが使用するルールの中で最も一般的で実用的なタイプです。ユーザーまたはプロセスが新しいリソースを作成すると、Kyverno はそのリソースのプロパティを検証ルールと照合し、検証に合格した場合はリソースの作成を許可します。検証に失敗した場合、作成はブロックされます。たとえば、すべてのポッドに kyverno というラベルを含めることを要求するポリシーを追加してみましょう。

 # 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] 属性が追加されます。

• 監査モードでは、ルール セットの 1 つ以上のルールに違反するリソースが作成されるたびに、承認レビュー要求が許可され、結果がレポートに追加されます。
• 強制モードでは、リソースは作成されるとすぐにブロックされ、報告されません。

次に、rules 属性を使用して定義されたルール セットがあります。 Match は一致するリソースを示すために使用され、validate は検証方法を示します。ここでは、kyverno: "?*" などのラベルを定義して、そのようなラベル キーが存在する必要があることを示します。

上記のポリシー オブジェクトを適用するだけです。

 ➜ 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

ここで、ラベル 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 タグが必要であることを示すプロンプトが表示されます。イベント イベントを表示することで、戦略の適用を理解することもできます。

 ➜ 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/

作成された Pod に kyverno ラベルが付いている場合は、通常どおり作成できます。

 ➜ kubectl run busybox --image=busybox:1.28.3 --labels kyverno=demo --restart=Never -- sleep 1000000 pod/busybox created

validationFailureAction の値を Audit に変更すると、作成した Pod は kyverno ラベルがなくても正常に作成されますが、PolicyReport オブジェクトで対応する違反レポートを確認できます。

 ➜ 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

上記のレポート リソースから、ポリシーに違反するリソース オブジェクトを確認できます。

ルールの変更

変更ルールは、ルールに一致するリソースを変更するために使用できます（たとえば、ルールが  metadata  フィールドはリソースに関連付けることができます  metadata  マージ（Merge）は、設定したルールに従って対応するリソースを変更することです。

たとえば、nginx イメージを含むすべてのポッドにラベル (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 即可

上記の戦略オブジェクトを適用するだけです。

 ➜ 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

ここで、nginx イメージを使用して 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 が正常に作成されると、kyverno=nginx ラベルが含まれていることがわかります。 kyverno ラベルのため、上記の検証ポリシーも通過し、正常に作成できます。

リソースを生成する

生成ルールは、新しいリソースが作成されたとき、または名前空間の新しい RoleBinding または Secrets を作成するなど、ソースが更新されたときに追加のリソースを作成するために使用できます。

たとえば、現在、私たちの要件の 1 つは、シークレットを他の名前空間 (TLS キー、イメージ リポジトリの認証情報など) と同期することです。これらのシークレットを手動でコピーするのは面倒なので、Kyverno を使用してこれらのシークレットを同期するための戦略を作成できます。たとえば、デフォルトの名前空間に regcred という名前の 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}}" # 获取目标命名空间synchronize: true clone: namespace: default name: regcred

まず、デフォルトの名前空間に 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

次に、上記の同期秘密戦略を適用します。

 ➜ 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

ここで、新しい名前空間を作成します。

 ➜ 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 はクラスター内のすべての Pod 間の通信を許可します。通信を制限するには、NetworkPolicy リソースと NetworkPolicy をサポートする CNI プラグインを使用する必要があります。各名前空間にデフォルトの NetworkPolicy を構成して、名前空間内の Pod のすべての受信トラフィックと送信トラフィックをデフォルトで拒否することができます。次に、選択したソースからアプリケーション ポッドへの必要なトラフィックを許可するように追加の NetworkPolicy リソースが構成されます。この時点で、このデフォルトの NetworkPolicy を自動的に作成するのに役立つ Kyverno ポリシーを作成することもできます。

 # 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 を定義します。

リソースのクリーンアップ

Kyverno は、クラスター内の既存のリソースを 2 つの異なる方法でクリーンアップ (つまり削除) できます。 1 つ目は、CleanupPolicy または ClusterCleanupPolicy での宣言型ポリシー定義です。 2 番目の方法は、リソースに保持期間 (TTL) ラベルを追加する方法です。

リソース内のイメージを検証、変更、生成、または確認する他のポリシーと同様に、Kyverno は CleanupPolicy と呼ばれる新しいポリシー タイプを定義することでリソースをクリーンアップできます。クリーンアップ ポリシーには、クラスター全体と名前空間全体の 2 種類があります。クリーンアップ ポリシーでは、使い慣れた一致/除外プロパティを使用して、クリーンアップ プロセスからリソースを選択および除外します。 Conditions{} プロパティ (オプション) は、前提条件や拒否ルールと同様の一般的な式を使用して、選択したリソースの内容を照会し、選択プロセスを絞り込みます。コンテキスト変数 (オプション) を使用すると、他のリソースからデータを取得し、クレンジング プロセスに組み込むことができます。最後に、スケジュール フィールドは、ルールをいつ実行するかを cron 形式で定義します。

たとえば、5 分ごとにスケジュールされたタスクでレプリカの数が 2 未満の場合、このクリーンアップ戦略により、タグ canremove:true を持つデプロイメントが削除されます。

 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 は最小権限の原則に準拠しているため、削除するリソースに応じてクリーンアップ コントローラーに追加の権限を付与する必要がある場合があります。 Kyverno は、新しいクリーンアップ ポリシーをインストールするときにこれらの権限を検証し、追加の権限が必要な場合に通知するのに役立ちます。たとえば、次の ClusterRole は、Kyverno が Pod をクリーンアップできるようにする権限ステートメントを示しています。

 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

どのリソースを削除するか、いつ削除するかのポリシーを宣言的に定義することに加えて、クリーンアップするもう 1 つの方法は、cleanup.kyverno.io/ttl というラベルを使用して、削除するリソースを明示的にマークすることです。このラベルは任意のリソースに割り当てることができ、Kyverno がリソースを削除するために必要な権限を持っている限り、指定された時間に削除されます。たとえば、以下の Pod を作成すると、Kyverno は 2 分後にそれをクリーンアップしますが、クリーンアップ ポリシーは存在しません。

 apiVersion: v1 kind: Pod metadata: labels: cleanup.kyverno.io/ttl: 2m name: foo spec: containers: - args: - sleep - 1d image: busybox:1.35 name: foo

ポリシー変数

変数を使用すると、ポリシー定義、アドミッション監査リクエスト、ConfigMap、Kubernetes API サーバー、OCI イメージ レジストリ、さらには外部サービス呼び出しなどの外部データ ソース内のデータへの参照が可能になり、ポリシーがよりスマートで再利用しやすくなります。

変数は JSON として保存され、Kyverno は JMESPath を使用して JSON データを選択および変換することをサポートしています。 JMESPath を使用すると、データ ソースの値は {{key1.key2.key3}} の形式で参照されます。たとえば、kubectl 適用操作中に新しい/受信リソースの名前を参照するには、変数参照として記述します: {{request.object.metadata.name}}。ルールを処理する前に、ポリシー エンジンは {{ <JMESPath> }} 形式の値を変数値に置き換えます。変数は、match または exclude ステートメントを除き、Kyverno ルールまたはポリシーのほとんどの場所で使用できます。

定義済み変数

Kyverno はいくつかの便利な変数を自動的に作成し、ルールで使用できるようにします。

• serviceAccountName:userName: たとえば、system:serviceaccount:nirmata:user1 からのリクエストを処理する場合、Kyverno は値 user1 を変数 serviceAccountName に保存します。
• serviceAccountNamespace: ServiceAccount の名前空間部分。たとえば、system:serviceaccount:nirmata:user1 からのリクエストを処理する場合、Kyverno は nirmata を変数 serviceAccountNamespace に保存します。
• request.roles: 特定のアカウントが持つ可能性のある、配列に格納されたロールのリスト。たとえば、["foo:dave"]。
• request.clusterRoles: 配列に保存されているクラスター ロールのリスト。たとえば、["dave-admin", "system:basic-user", "system:discovery", "system:public-info-viewer"]。
• images: コンテナイメージ情報のマップ（存在する場合）。

ポリシー定義の変数

Kyverno ポリシー定義では、ポリシー定義内の他のフィールドをショートカットとして参照できます。これは、値を明示的に定義せずに分析および比較するのに便利な方法です。 Kyverno がマニフェスト内のこれらの既存の値を参照するために、$(./../key_1/key_2) という表記を使用します。これは、Linux/Unix システムが相対パスを参照する方法と本質的に同じであるため、見覚えがあるかもしれません。

たとえば、次のポリシー マニフェスト スニペット:

 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 仕様で見つかったコンテナのフィールド readinessProbe.tcpSocket.port は 3000 で、フィールド livenessProbe.tcpSocket.port は同じ値である必要があります。

変数のエスケープ

場合によっては、Kyverno が使用するのではなく、別のプログラムまたはプロセスが動作するための変数を含むルールを記述する必要があることがあります。たとえば、$() 表記の変数の場合、先頭にバックスラッシュ (\) を付けてエスケープすると、Kyverno は値を置き換えようとしなくなります。 JMESPath 表記で記述された変数も、同じ構文を使用してエスケープできます (例: \{{ request.object.metadata.name }})。

次のポリシーでは、OTEL_RESOURCE_ATTRIBUTES の値に、$(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)

たとえば、次のように 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

OTEL_RESOURCE_ATTRIBUTES 環境変数に対するこの Pod の結果は次のようになります。

 - 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 のポリシーの詳細については、公式 Web サイト (https://kyverno.io/policies) をご覧ください。ポリシーの種類、カテゴリ、テーマなどでフィルタリングできます。Kyverno は柔軟性、パワー、使いやすさのバランスが取れています。学習にそれほど時間をかける必要はなく、非常に便利な機能を提供できます。公式サイトでは、さまざまなシナリオのサンプルが多数提供されており、非常に活用する価値があります。さらに、リソース戦略をテストするために公式の Kyverno Playground も使用します。