Kyverno による Kubernetes ポリシー管理

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

対比

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

ゲートキーパーの利点

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

ゲートキーパーの欠点

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

Kyvernoの利点

• Kubernetes スタイルのポリシー表現。非常に簡単に記述できます。
• 成熟した突然変異能力。
• 独自の生成および同期機能により、アプリケーション シナリオが拡張されます。
• 迅速な配信と豊富なシナリオ。

Kyvernoの欠点

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

上記の比較から、Gatekeeper の最大の弱点は、ポリシー ロジックを実装するために Rego 言語が必要であり、この言語は他の場所では使用できないため、敷居が大幅に高くなることがわかります。もちろん、プログラミング言語は非常に強力なロジックを実装できるため、これも利点です。 Gatekeeper と比較すると、Kyverno の第一印象は、Kubernetes 専用に構築されており、ポリシーを表現するために宣言的なアプローチを使用しているため、そのモデルが Kubernetes オブジェクトの記述と調整と同じであるため、それほど複雑な技術要件がないということです。このモデルにより、ポリシーの記述方法が大幅に簡素化され、ポリシー エンジンの使用の難しさが総合的に軽減されます。さらに、Kyverno のコンパイルおよび生成機能により、Kyverno は単純なアドミッション コントローラーから真の自動化ツールへと進化します。これら 3 つの機能と、最近追加された API クエリ機能を組み合わせることで、Kyverno は Gatekeeper では実行できないタスクを実行できるようになります。このシンプルさと自動化機能、および他のツールとの統合を組み合わせることで、新規ユーザーだけでなく経験豊富なユーザーやオペレーターにも大きな価値をもたらします。

もちろん、選択する特定のツールはニーズと制約に基づいて評価する必要がありますが、すべての本番環境ユーザーは、クラスターのセキュリティを保護し、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 kyverno
 クラスターポリシー。 キベルノ。 イオ2022-03-29 T07 : 21 : 22Z
 クラスターレポート変更リクエスト。 キベルノ。 イオ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 - ラベル.yaml
 apiバージョン: kyverno.io/v1
 種類: ClusterPolicy
 メタデータ:
 名前: 必須- ラベル
仕様:
 検証失敗アクション: 強制
ルール:
 - 名前: ラベルをチェック​
 マッチ：
 リソース：
 種類:
 - ポッド
検証:
 メッセージ: 「ラベル 'kyverno' が必要です」
 パターン：
 メタデータ:
 ラベル:
 kyverno : 「?*」

上記のポリシー ファイルに、validationFailureAction=[audit, enforce] 属性が追加されます。

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

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

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

 ➜ kubectl apply -f kyverno -require -label .yaml ​ ​ ​
 クラスターポリシー。 キベルノ。 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 警告ポリシー違反デーモンセット/ スピーカーポリシー「require-label」 ( 検証) ルール「autogen-check-for-labels」 が失敗しました。 検証エラー: ラベル「kyverno」 が必要です。 ルールautogen - check - for - labels がパス/ spec / template / metadata / labels / kyverno / で失敗しました
デフォルト0 秒警告ポリシー違反clusterpolicy / require - ラベル

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

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

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

 ➜ kubectl ポリシーレポートを取得する
名前合格不合格警告エラースキップ年齢
polr - ns - デフォルト0 2 0 0 0 20 m
 ➜ kubectl ポリシーレポートを記述します| grep "結果: \+fail" - B10
 UID : 90d1dfc7-0e42-4133-8a65-4bbf559533a2
 結果：
 メッセージ: 検証エラー: ラベル「kyverno」が必要です。 ルールautogen - check - for - labels がパス/ spec / template / metadata / labels / kyverno / で失敗しました
ポリシー: 必須- ラベル
リソース：
 API バージョン: アプリ/ v1
 種類: 展開
名前: ミニオ
名前空間: デフォルト
UID : 86ccd8fc - 07f6-47a4 - a9ed - b9dec665dff3
 結果： 不合格
--
 ナノ: 0
 秒数: 1648541980
 メッセージ: 検証エラー: ラベル「kyverno」が必要です。 ルールチェック- for - ラベルがパス/ 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 ​ ​ ​
 クラスターポリシー。 キベルノ。 io / nginx - ラベルが作成されました
➜ kubectl クラスターポリシーを取得する
名前背景アクション準備完了
nginx - ラベルtrue 監査true
 必要- ラベルはtrue 強制はtrue

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

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

Pod が正常に作成されると、kyverno=nginx ラベルが含まれていることがわかります。 kyverno ラベルのため、上記の検証ポリシーも通過し、正常に作成できます。

リソースを生成する

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

たとえば、シークレットを他の名前空間（TLS キー、イメージ リポジトリの認証情報など）に同期する必要がある場合、これらのシークレットを手動でコピーするのは面倒です。 Kyverno を使用すると、これらの秘密を同期するための戦略を作成できます。たとえば、デフォルトの名前空間に regcred という名前の Secret オブジェクトがあり、これを別の名前空間にコピーする必要があります。ソース シークレットが変更されると、コピーされたシークレットも同期的に更新されます。

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

まず、デフォルトの名前空間に Secret オブジェクトを準備します。

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