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.26.x がインストールされていますので、最新バージョン 1.9.2 をインストールすることを選択してください。

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

 ➜ kubectl create -f https://github.com/kyverno/kyverno/releases/download/v1.9.2/install.yaml

さらに、ワンクリック インストールに Helm を使用することもできます。

 ➜ Helmリポジトリにkyvernoを追加https://kyverno.github.io/kyverno/
 ➜ helmリポジトリの更新
# Kyverno Helmチャートを「kube-kyverno」という新しい名前空間にインストールします
➜ Helmアップグレード-- kyvernoをインストールしますkyverno / kyverno - n kube - kyverno -- create - namespace
リリース「kyverno」は存在しません。今インストールしています。
名前: kyverno
最終展開: 2023年4月11日火曜日15:51:30
名前空間: kube - kyverno
ステータス:展開済み
改訂: 1
注記:
チャートバージョン: 2.7.2
 Kyvernoバージョン: v1.9.2

 kyvernoをインストールしていただきありがとうございます!リリースの名前はkyvernoです。
 ⚠️警告:レプリカ数を3未満に設定すると、 Kyverno は高可用性モードで実行されません。

 💡注意:名前空間の除外に関してどのアプローチを取るかを決定する際にはトレードオフが存在します。リスクを理解するには、 https ://kyverno.io/docs/installation/#security-vs-operabilityのドキュメントを参照してください。

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

 ➜ kubectl get pods - n kube - kyverno
名前準備完了ステータス再起動年齢
kyverno - 8657 b8cfcf - mgtsr 1 / 1ランニング0 2 m25s
 kyverno -クリーンアップ-コントローラー- 5 c964d77dc - 5 s5zp 1 / 1実行中0 2分25秒
➜ kubectl で検証Webhook設定を取得
名前ウェブフック年齢
kyverno -クリーンアップ-検証- webhook - cfg 1 44 m
 kyverno -例外-検証- webhook - cfg 1 16 m
 kyverno -ポリシー-検証- webhook - cfg 1 16 m
 kyverno -リソース-検証- webhook - cfg 0 16 m
 ➜ kubectl でmutatingwebhookconfigurationsを取得します
名前ウェブフック年齢
kyverno -ポリシー-変更- webhook - cfg 1 17 m
 kyverno -リソース-変更- webhook - cfg 0 17 m
 kyverno -検証-変更- webhook - cfg 1 17 m
 ➜ kubectl でcrdを取得します| grep kyverno
 admissionreports.kyverno.io2023-04-11T07 : 51 : 33Z
背景スキャンレポート。キベルノ。イオ2023-04-11 T07 : 51 : 33Z
クリーンアップポリシー。キベルノ。イオ2023-04-11 T07 : 51 : 33Z
クラスター入場レポート。キベルノ。イオ2023-04-11 T07 : 51 : 33Z
クラスター背景スキャンレポート。キベルノ。イオ2023-04-11 T07 : 51 : 33Z
クラスタークリーンアップポリシー。キベルノ。イオ2023-04-11 T07 : 51 : 33Z
クラスターポリシー。キベルノ。イオ2023-04-11 T07 : 51 : 34Z
リクエストを生成します。キベルノ。イオ2023-04-11 T07 : 51 : 33Z
ポリシー。キベルノ。イオ2023-04-11 T07 : 51 : 34Z
ポリシー例外。キベルノ。イオ2023-04-11 T07 : 51 : 33Z
更新リクエスト。キベルノ。イオ2023-04-11 T07 : 51 : 33Z

インストールが完了すると、いくつかの 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 : 「?*」

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

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

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

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

 ➜ kubectl apply -f kyverno -require -label .yaml​​​
クラスターポリシー。キベルノ。 io / require -ラベル-ポリシーが作成されました
➜ kubectlクラスターポリシーを取得する
名前経歴検証アクション準備年齢
要求-ラベル-ポリシーtrue trueを強制4 m23s

ここで、ラベル kyverno のない Pod を追加します。

 ➜ kubectl run busybox --image = busybox : 1.28 .3 --restart = Never --sleep 1000000​​
サーバーからのエラー:アドミッションWebhook 「validate.kyverno.svc-fail」がリクエストを拒否しました:

リソース違反のポリシーPod / default / busybox :

必須-ラベル-ポリシー:
ラベルの確認: 「検証エラー: ラベル'kyverno' 'が必要です。ルール ラベルのチェック
パス/メタデータ/ラベル/ kyverno / 'で失敗しました

kyverno タグが必要であることを示すプロンプトが表示されます。イベント イベントを表示することで、戦略の適用を理解することもできます。

 ➜ kubectlイベントを取得- A - w
 ......
 for -ラベルが失敗しました:検証エラー:ラベル'kyverno'が必要です。ルールautogen - check - for - labels がパス/ spec / template / metadata / labels / kyvernoで失敗しました/
 qdrant - system 51 s警告ポリシー違反pod / qdrant - 0ポリシーrequire - label - policy / check - for - labelsが失敗しました:検証エラー:ラベル'kyverno'が必要です。ルールチェック- for -ラベルがパス/メタデータ/ラベル/ kyverno /で失敗しました
qdrant - system 50秒警告PolicyViolation statefulset / qdrantポリシーrequire - label - policy / autogen - check - for - labelsが失敗しました:検証エラー:ラベル'kyverno'が必要です。ルールautogen - check - for - labels がパス/ spec / template / metadata / labels / kyvernoで失敗しました/

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

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

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

 ➜ kubectlポリシーレポートを取得する
名前合格不合格警告エラースキップ年齢
cpol -必要-ラベル-ポリシー0 1 0 0 0 4分42秒
➜ kubectlポリシーレポートを記述します| grep "結果: \+fail" - B10
 UID : def28081 - aa68-4e96 - bb43 - fdc73274df00
結果：
メッセージ:検証エラー:ラベル「kyverno」が必要です。ルールチェック- for -ラベルがパス/メタデータ/ラベル/ kyverno /で失敗しました
ポリシー:必須-ラベル-ポリシー
リソース：
 APIバージョン: v1
種類:ポッド
名前:ビジーボックス
名前空間:デフォルト
UID : 9667e83d - 62a3-4844 - b5d7 - da127e9cee2c
結果：不合格

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

ルールの変更

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

たとえば、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 6秒

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

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

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

リソースを生成する

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

たとえば、現在、私たちの要件の 1 つは、シークレットを他の名前空間 (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クラスターポリシーを取得する
名前背景アクション準備完了
同期-シークレット-ポリシーtrue監査true 9秒

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

 ➜ kubectl作成nsテスト
名前空間/テストを作成しました
➜ kubectlシークレットを取得- nテスト
名前タイプデータ年齢
kubernetes .io / dockerconfigjson 1 6秒を登録しました

新しく作成された名前空間に、regcred という名前の追加の Secret オブジェクトがあることがわかります。

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

たとえば、NGINX Ingress のパス値を制限するには、次のようなポリシーを作成します (CVE-2021-25745 セキュリティ問題、NGINX Ingress v1.2.0 で修正済み)。

 apiバージョン: kyverno.io/v1
種類: ClusterPolicy
メタデータ:
名前:制限-進入-パス
注釈:
ポリシー。キベルノ。 io / title : NGINX Ingressパス値を制限する
ポリシー。キベルノ。 io /カテゴリ:セキュリティ、 NGINX Ingress
ポリシー。キベルノ。 io /重大度：高
ポリシー。キベルノ。 io /件名: Ingress
ポリシー。キベルノ。 io /最小バージョン: "1.6.0"
 kyverno.io/kyverno-version : " 1.6.0 "
 kyverno .io / kubernetes -バージョン： 「1.23」
ポリシー。キベルノ。 io /説明: >-
このポリシーは、 `specを制限することでCVE - 2021-25745を軽減します。ルール[]。 http://www.youtube.com/watch?v=vUyQyYyxcパス[]。安全な値へのパス` 。
必要に応じて追加のパスを追加できます。この問題は、 NGINX Ingress v1.2.0で修正されました。
詳細についてはCVEを参照してください。
仕様:
検証失敗アクション:強制
ルール:
 -名前:チェック-パス
マッチ：
どれでも：
 -リソース：
種類:
 -ネットワーキング。 k8s 。 io / v1 /イングレス
検証:
メッセージ: "spec.rules[].http.paths[].path 値は許可されていません"
拒否：
条件：
どれでも：
 -キー: "{{ request.object.spec.rules[].http.paths[].path.contains(@,'/etc') }}"
演算子: AnyIn
値: [ true ]
 -キー: "{{ request.object.spec.rules[].http.paths[].path.contains(@,'/var/run/secrets') }}"
演算子: AnyIn
値: [ true ]
 -キー: "{{ request.object.spec.rules[].http.paths[].path.contains(@,'/root') }}"
演算子: AnyIn
値: [ true ]
 -キー: "{{ request.object.spec.rules[].http.paths[].path.contains(@,'/var/run/kubernetes/serviceaccount') }}"
演算子: AnyIn
値: [ true ]
 -キー: "{{ request.object.spec.rules[].http.paths[].path.contains(@,'/etc/kubernetes/admin.conf') }}"
演算子: AnyIn
値: [ true ]