[Kyverno] クイックスタートガイド

“この投稿は、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:
  # Podに関連するマッチが発生した場合にチェックを実行するcheck-teamというルールを作成
  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専用に書かれたポリシーを、Deploymentを含むすべての標準Kubernetes Podコントローラーにインテリジェントに適用します。

次に、必須ラベルを含めて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-labels

---

3. リソースの生成 (Generate Resources)

Kyvernoには、ポリシーに保存された定義に基づいて新しいKubernetesリソースを生成する機能があります。生成機能は非常に強力で柔軟であり、初期生成だけでなく、生成されたリソースを継続的に同期する機能も提供します。

このガイドでは、新しいネームスペースが作成されたときにイメージプルシークレットを自動的に生成するポリシーを見ていきます。まず、実際のシークレットを模倣したテスト用のシークレットを作成します。

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:
  # 今回はNamespaceの作成が検出された場合に動作
  rules:
  - name: sync-image-pull-secret
    match:
      any:
      - resources:
          kinds:
          - Namespace
    # Secretを要求されたNSに作成するルールが含まれており、これは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