OPAのGatekeeperとKyvernoは、CNCFの主要なポリシー管理プロジェクトです。それぞれに独自の利点があります。Gatekeeperについては既に学習しました。次はKyvernoの使い方を学びます。

KyvernoはNirmataが開発したオープンソースプロジェクトで、後にCNCFに寄贈されました。Gatekeeperと同様に、Kyvernoは検証と変更機能を備えたKubernetesポリシーエンジンですが、リソース生成機能とAPIオブジェクトクエリ機能も追加されています。Gatekeeperとは異なり、Kyvernoは元々Kubernetes向けに開発されました。Gatekeeperと比較すると、Kyvernoはオブジェクト生成機能以外にポリシー記述に専用の言語を必要としません。実装言語の観点から見ると、Kyvernoのモデルはよりシンプルです。GatekeeperのRego言語には、ある程度の学習曲線があります。

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

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

キヴェルノ建築

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

対比

Gatekeeper と Kyverno はどちらもポリシー管理プロジェクトなので、これら 2 つのプロジェクトの長所と短所を比較するのは当然です。

ゲートキーパーの利点

• 非常に複雑な戦略を表現できます。
• コミュニティはより成熟しています。
• 可用性とスケーラビリティを向上させるために、マルチレプリカ モードをサポートしています。

ゲートキーパーの欠点

• プログラミング言語のサポートが必要になりますが、学習曲線が急峻で、大量の技術的負債が発生し、納品時間が長くなる可能性があります。
• 生成能力がないため、主な適用シナリオは検証となります。
• この戦略は複雑かつ長く、それを実行するには複数のオブジェクトが連携して動作する必要があります。

Kyvernoの利点

• Kubernetes スタイルのポリシー表現は非常に簡単に記述できます。
• 成熟した変異能力。
• 独自の生成および同期機能により、アプリケーション シナリオが拡大します。
• 迅速な納品、多様なアプリケーションシナリオ。

Kyvernoの欠点

• 言語能力によって制限されるため、複雑な戦略を実行することは困難です。
• 彼らは比較的若く、コミュニティにあまり受け入れられていません。
• API のオブジェクト クエリ機能はまだ非常に初歩的な段階にあります。

上記の比較から、Gatekeeperの最大の弱点は、ポリシーロジックの実装にRego言語に依存していることが分かります。この言語は他では利用できません。これにより参入障壁が大幅に高まりますが、プログラミング言語では非常に強力なロジックを実装できるため、メリットにもなり得ます。対照的に、Kyvernoの第一印象は技術要件の低さです。Kubernetes専用に構築されており、宣言的なアプローチでポリシーを表現し、Kubernetesオブジェクトの記述と調整方法にモデルを合わせています。これにより、ポリシーの記述が大幅に簡素化され、ポリシーエンジンの使用難易度が大幅に軽減されます。さらに、Kyvernoのコンパイルおよび生成機能により、単純なアドミッションコントローラーから真の自動化ツールへと変貌を遂げています。これら3つの機能と、最近追加されたAPIクエリ機能を組み合わせることで、KyvernoはGatekeeperではできないタスクを実行できます。このシンプルさと自動化機能、そして他のツールとの統合により、初心者と経験豊富なユーザー、そしてオペレーターの両方に計り知れない価値をもたらします。

もちろん、選択する特定のツールは、独自のニーズと制約に基づいて評価する必要がありますが、1 つ確かなことは、実稼働環境のすべてのユーザーは、クラスターのセキュリティを保護し、Kubernetes の管理を簡素化するために、ポリシー エンジンの使用を計画する必要があるということです。

インストール

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

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

あるいは、Helm を使用してワンクリック インストールを行うこともできます。

 ➜ Helm リポジトリにkyverno を追加https://kyverno.github.io/kyverno/
 ➜ helm リポジトリの更新
# Kyverno Helm チャートを「kyverno」 という新しい名前空間にインストールします
➜ helm install kyverno kyverno / kyverno - n kyverno -- create - 名前空間

インストール後、kyverno 名前空間が作成され、関連する CRD もいくつか含まれます。

 ➜ kubectl ポッドを取得- n kyverno
 名前準備完了ステータス再起動年齢
カイバーノ- 69 bdfcfc7c - dbtlt 1 / 1 ランニング0 29 m
 ➜ kubectl で検証Webhook構成を取得します
名前ウェブフック年齢
kyverno - ポリシー- 検証- webhook - cfg 1 14 m
 kyverno - リソース- 検証- webhook - cfg 2 14 m
 ➜ kubectl でmutatingwebhookconfigurations を取得します
名前ウェブフック年齢
kyverno - ポリシー- 変更- webhook - cfg 1 14 m
 kyverno - リソース- 変更- webhook - cfg 2 14 m
 kyverno - 検証- 変更- webhook - cfg 1 14 m
 ➜ kubectl でcrd を取得| grep カイバーノ
クラスターポリシー。 カイバーノ。 イオ2022-03-29 T07 : 21 : 22Z
 クラスターレポート変更リクエスト.kyverno.io 2022-03-29 T07 : 21 : 22Z
 リクエストを生成します。 カイバーノ。 イオ2022-03-29 T07 : 21 : 22Z
 ポリシー.kyverno .io 2022-03-29 T07 : 21 : 22Z
 レポート変更リクエスト。 カイバーノ。 イオ2022-03-29 T07 : 21 : 23Z

ご覧のとおり、インストール後にいくつかの 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
 apiバージョン: kyverno.io/v1
 種類: ClusterPolicy
 メタデータ
名前: 必須- ラベル
仕様:
 検証失敗アクション: 強制
ルール：
 - 名前: ラベルのチェック​
 マッチ：
 リソース：
 種類:
 - ポッド
検証:
 メッセージ: 「ラベル 'kyverno' が必要です」
 パターン：
 メタデータ
ラベル:
 kyverno : "?*"

上記のポリシー ファイルには、`validationFailureAction=[audit, enforce]` 属性が含まれています。

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

次は、`rules` 属性を使用して定義される一連のルールです。`match` は照合するリソースを指定するために使用され、`validate` は検証方法を指定します。ここでは、`kyverno: "?*"` のようなタグを定義して、そのようなタグキーが必須であることを示します。

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

 ➜ kubectl apply -f kyverno -require -label .yaml ​ ​ ​
 clusterpolicy.kyverno.io/require - ラベルが作成されました
➜ kubectl でクラスターポリシーを取得する
名前背景アクション準備完了
必要- ラベルはtrue、 強制はtrue

次に、「kyverno」タグなしで Pod を追加してみましょう。

 ➜ kubectl run busybox -- image = busybox : 1.28 .4 -- restart = Never -- sleep 1000000
 サーバーからのエラー: アドミッションWebhook 「validate.kyverno.svc-fail」がリクエストを拒否しました:
 リソースPod / default /busybox は、以下のポリシーによりブロックされました
必要- ラベル:
 ラベルのチェック: '検証エラー: ラベル ' 'kyverno' ' が必要です。 ルールのラベルのチェック
パス/ メタデータ/ ラベル/ kyverno / ' で失敗しました

ご覧の通り、kyvernoタグが必要です。同様に、イベントセクションでポリシーがどのように適用されているかを確認できます。

 ➜ kubectl イベントを取得- A - w
 …… ​
 metallb - システム9 m25s 警告ポリシー違反daemonset / speaker ポリシー'require-label' ( 検証) ルール'autogen-check-for-labels' が失敗しました。 検証エラー: ラベル'kyverno'が必要です。 ルールautogen - check - for - labels がパス/ spec / template / metadata / labels / kyverno / で失敗しました。
 デフォルト0 秒警告ポリシー違反クラスターポリシー/ 要求- ラベル

作成する Pod に kyverno タグが付いている場合は、通常どおり作成できます。

 ➜ kubectl run busybox -- image = busybox : 1.28 .4 -- labels kyverno = demo -- restart = Never -- sleep 1000000
 ポッド/ ビジーボックスが作成されました

validationFailureAction の値を audit に変更すると、kyverno タグが付いていない場合でも、作成する Pod は正常に作成されます。ただし、対応する違反レポートは PolicyReport オブジェクトで確認できます。

 ➜ kubectl ポリシーレポートを取得する
名前合格不合格警告エラースキップ年齢
polr - ns - デフォルト0 2 0 0 0 20 m
 ➜ kubectl describe policyreports | grep "結果: \+fail" - B10
 UID : 90d1dfc7-0e42-4133-8a65-4bbf559533a2
 結果：
 メッセージ: 検証エラー: ラベル「kyverno」 が必要です。 ルールautogen - check - for - labels がパス/ spec / template / metadata / labels / kyverno / で失敗しました。
 ポリシー: 必須- ラベル
リソース：
 API バージョン: apps / v1
 種類: 展開
名前： ミニオ
名前空間: デフォルト
UID : 86ccd8fc - 07f6-47a4 - a9ed - b9dec665dff3
 結果： 不合格
--
 ナノ： 0
 秒数: 1648541980
 メッセージ: 検証エラー: ラベル「kyverno」 が必要です。 パス/ metadata / labels / kyverno / でラベルのルールチェックが失敗しました。
 ポリシー: 必須- ラベル
リソース：
 API バージョン: v1
 種類: ポッド
名前: ビジーボックス
名前空間: デフォルト
UID : 7e593177-4366-462b - 81cf - 1057657ae099
 結果： 不合格

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

ルールを変える

ルールを変更すると、ルールに一致するリソースを変更できます (たとえば、ルールによってリソースのメタデータと結合できるメタデータ フィールドが設定されている場合)。つまり、設定したルールに従って対応するリソースが変更されます。

たとえば、nginx イメージを含むすべてのポッドにタグ (kyverno=nginx) を追加する、次のようなポリシーを追加します。

 # kyverno - 変異- ラベル.yaml
 apiバージョン: kyverno.io/v1
 種類: ClusterPolicy
 メタデータ
名前: nginx - ラベル
仕様:
 ルール：
 - 名前: nginx - ラベル
マッチ：
 リソース：
 種類:
 - ポッド
変異する
パッチ戦略的マージ:
 メタデータ
ラベル:
 kyverno : nginx
 仕様:
 （ コンテナ）:
 - ( image ): "*nginx*" # コンテナイメージにはnginxが含まれている必要があります。

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

 ➜ kubectl apply -f kyverno -mutate -label .yaml ​ ​ ​
 clusterpolicy.kyverno.io/nginx - ラベルが作成されました
➜ kubectl でクラスターポリシーを取得する
名前背景アクション準備完了
nginx - ラベルtrue 監査true
 必要- ラベルはtrue、 強制はtrue

ここで、nginx イメージを使用して Pod を直接作成します。

 ➜ kubectl run --image = nginx nginx ​
 pod / nginx を作成しました
➜ kubectl get pod nginx -- show - ラベル
名前準備完了ステータスが年齢ラベルを再開
nginx 1/1 実行中0 29 秒kyverno = nginx 、 run = nginx

ご覧の通り、Podは正常に作成され、kyverno=nginxタグが含まれています。kyvernoタグのおかげで上記の検証戦略は成功し、Podを正常に作成できます。

リソースを生成する

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

例えば、特定のシークレット（TLSキーやミラーリポジトリの認証情報など）を他の名前空間に同期する必要がある場合、これらのシークレットを手動でコピーするのは面倒です。Kyvernoを使用すれば、これらのシークレットを同期するための戦略を作成できます。例えば、`default`名前空間に`regcred`という名前のシークレットオブジェクトがあり、これを別の名前空間にコピーする必要がある場合、コピー元のシークレットが変更されると、コピー先のシークレットも更新されます。

 # kyverno - 生成- シークレット.yaml
 apiバージョン: kyverno.io/v1
 種類: ClusterPolicy
 メタデータ
名前: 同期- 秘密
仕様:
 ルール：
 - 名前: 同期- イメージ- プル- シークレット
マッチ：
 リソース：
 種類:
 - 名前空間
generate : # 生成されたリソースオブジェクト
種類: 秘密
名前: regcred
 namespace : "{{request.object.metadata.name}}" # 対象の名前空間を取得する
同期: true
 クローン:
 名前空間: デフォルト
名前: 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 が作成されました

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

 ➜ kubectl apply -f kyverno -generate -secret .yaml ​ ​ ​
 clusterpolicy.kyverno.io/sync - シークレットが作成されました
➜ kubectl でクラスターポリシーを取得する
名前背景アクション準備完了
nginx - ラベルtrue 監査true
 必要- ラベルはtrue、 強制はtrue
 同期- シークレットtrue 監査true

次に、新しい名前空間を作成しましょう。

 ➜ kubectl ns テストを作成
名前空間/ テストを作成しました
➜ kubectl シークレットを取得- n テスト
名前タイプデータ年齢
デフォルト- トークン- 7 b7cv kubernetes .io / サービス- アカウント- トークン3 7 s
 kubernetes .io / dockerconfigjson 1 6 秒を登録しました

ご覧のとおり、新しく作成された名前空間に新しい regcred Secret オブジェクトが作成されています。

Kyvernoのポリシーは公式サイト（https://kyverno.io/policies）でご覧いただけます。ポリシーは種類、カテゴリ、テーマなどで絞り込むことができます。Kyvernoは柔軟性、パワー、使いやすさのバランスが取れています。多くの学習時間を必要とせず、便利な機能を提供します。公式サイトには様々なシナリオに対応した豊富な例が掲載されているため、ぜひ活用してみてください。