Kubernetes ポリシー エンジン Kyverno の使用

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
最終展開: 20234月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 11kyverno = 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参照してください
仕様:
検証失敗アクション:強制
ルール:
-名前:チェック-パス
マッチ
どれでも
-リソース
種類:
-ネットワーキングk8sio / 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 ]

<<:  Yifupayクラウドネイティブデータ開発およびガバナンスプラットフォームの実践

>>:  クラウド関連の IoT 脅威を軽減する方法

推薦する

クラスターのネームスペースを削除できないのはなぜですか?

背景今日議論する問題は、K8s クラスターの名前空間に関連しています。名前空間は、K8s クラスター...

SEO最適化は4つの重要なスキルを発表

SEO最適化は現在、産業化に向けて進んでいます。私がネットワーク最適化を始めた頃は、クリエイティブな...

共同購入ウェブサイトは独立性を失いつつあり、業界大手の手足となっている

潮が引いたときに初めて、誰が裸で泳いでいるかが分かります。 「何千もの共同購入戦争」を経験した後、共...

SEO実践の4つの側面

SEOのベストプラクティスこの記事のおすすめ 検索エンジンの置き換えに伴い、SEO の実践も常に進化...

Yunbase: ロサンゼルス cn2 gia 高防御サーバー、最大 500G DDoS 防御、CC 攻撃を無視

Yunbaseは2009年に設立されました。プロジェクト転換を経て、現在は主に独立サーバーを運営して...

コミュニティ運営にゲーミフィケーション思考を応用!

前回の記事「企業にとってのコミュニティの具体的な価値とは」では、企業にとってのコミュニティの価値につ...

Funshare Sales: ハイテク産業を深く育成し、企業のコア競争力の向上を支援

[51CTO.comよりオリジナル記事] 顧客関係管理の概念と提案以来、多くの業界で広く利用されてき...

Linodeはどうですか?ワシントンDCデータセンタークラウドサーバー評価データ共有

Linodeはどうですか? linode ワシントンDCはどうですか? Linode 社も米国の首都...

Baidu のインデックスをゼロから通常の状態に戻すにはどうすればよいですか?

ホームページを構築してから半年以上が経ちました。何も知らなかった初心者から、ホームページがある程度完...

Red Hat Kubernetesレポート: セキュリティは最大の課題であり、問​​題の核心は人にある

Red Hat は、クラウドネイティブ開発において組織が直面するセキュリティ上の課題と、アプリケーシ...

靴のB2Cの失敗:Letao.comが売却されたが、購入者が誰なのか誰も知らない?

Chaogeは昨日Fantong.comの閉鎖を最初に報じ、広範囲にわたる再投稿を引き起こした。今日...

AWS ECS と AWS Lambda: 5 つの主な違い

AWS ECS と AWS Lambda は特定の目的に適しているため、適切なものを選択することがク...

Aoyoyun (Aoyou Host、Aoyou Cloud) 香港クラウドデータセンター高帯域幅 VPS の簡単なレビュー

2018年2月に香港クラウドデータセンターのMaxthon Hostingの高帯域幅VPS(Maxt...

Kubernetesネットワークモデルの包括的なガイドについてお話ししましょう

この詳細なブログ投稿では、Kubernetes ネットワークの複雑さについて説明し、コンテナ化された...

VMware 仮想ラボの構築に関する 3 つの FAQ

ミニ PC (Intel の Next Unit of Computing デバイスや MSI の ...