Kyverno は、Kubernetes ネイティブに設計されたポリシーエンジンであり、Policy-as-Code アプローチを使用してセキュリティ、コンプライアンス、および自動化ポリシーを管理できます。Container Service for Kubernetes (ACK) のデフォルトのポリシーエンジンである Open Policy Agent (OPA) Gatekeeper の代替として、Kyverno を使用すると、標準の YAML を使用してポリシーを定義でき、Rego のような専門言語を学習する必要がなくなります。また、アドミッションコントロールプロセス中にリソースのミューテーションと生成をサポートしているため、高度にカスタマイズされたポリシー、O&M の自動化、またはマルチクラスターポリシーガバナンスを必要とするシナリオに最適です。
仕組み
Kyverno は、Kubernetes クラスター内で動的アドミッションコントローラーとして実行されます。API サーバーからのアドミッション Webhook リクエストをインターセプトし、検証またはミューテーション操作を実行した後、リクエストを許可または拒否する決定を返します。
次の図は、Kyverno がアドミッション Webhook を使用して、API サーバーのアドミッションフェーズ中にポリシーを検証し、リソースをミューテーションする仕組みを示しています。
ユースケース
デフォルトの ACK セキュリティポリシー管理機能は OPA Gatekeeper 上に構築されています。一般的なコンプライアンスおよび O&M のユースケースに対応するコンテナセキュリティポリシーライブラリが組み込まれており、一般的な監査および適用のニーズを満たします。また、複数のポリシーインスタンスのデプロイをサポートし、Simple Log Service (SLS) と統合して可観測性を向上させます。
Kyverno は Kubernetes ネイティブのポリシーエンジンです。標準の CustomResourceDefinition (CRD) を使用してポリシーを定義および管理し、シンプルでユーザーフレンドリなエクスペリエンスを提供します。その主な利点は次のとおりです：
YAML ベースのポリシー：ポリシーは標準の YAML で記述され、他の Kubernetes マニフェストと一貫性があります。これにより、Rego のような専門言語を学習する必要がなくなり、学習のハードルが下がります。
豊富な機能セット：Kyverno はネイティブで
validate、mutate、generate操作をサポートしています。これにより、より広範な自動化および Policy-as-Code のユースケースをカバーします。既存リソースのスキャン：アドミッション時にポリシーを適用することに加えて、Kyverno はクラスター内の既存リソースの設定をスキャン、レポート、ミューテーション、生成することもできます。
リソースの自動生成：ポリシーは、
NetworkPolicyやConfigMapなどの関連リソースを自動的に作成し、自動化された構成を可能にします。
Kubernetes は現在、ネイティブの ValidatingAdmissionPolicy および MutatingAdmissionPolicy を提供していますが、Kyverno はより包括的でエンタープライズレベルのポリシーガバナンス機能を提供します。
推奨されるユースケース：
カスタムポリシー：ご利用の CRD 用のポリシーを迅速に記述し、デプロイします。
ミューテーションおよび生成ポリシー：
mutateまたはgenerateポリシーを使用する必要がある場合。Kyverno は、包括的なキャッシュ、外部データ統合、およびレポートメカニズムを備えています。その拡張された Common Expression Language (CEL) 構文ライブラリは、特定のエンタープライズシナリオにおける高度な Policy-as-Code のニーズを満たすことができます。
マルチクラスターポリシーガバナンス：Kyverno CLI、API、または ArgoCD などの GitOps ツールとの統合を使用して、複数のクラスターにわたる統一されたポリシーの配布と管理を実現します。
前提条件
Kubernetes バージョン 1.30 以降を実行している ACK マネージドクラスターまたは ACK 専用クラスターが必要です。必要に応じて、クラスターをアップグレードしてください。
Kyverno は、Kubernetes コミュニティの N-2 バージョンスキューポリシーに従い、現在のリリースと過去 2 つのマイナーリリースを公式にサポートしています。N-2 より古いバージョンは完全にはテストされておらず、互換性は保証されていません。詳細な内訳については、公式の Kyverno 互換性マトリックスをご参照ください。
Kyverno のインストール
クラスター ページで、対象のクラスターを見つけてその名前をクリックします。左側のナビゲーションウィンドウで、 を選択します。
[デプロイ] をクリックし、画面の指示に従って kyverno を検索して選択します。最新のチャートバージョンを選択し、必要に応じてパラメーターを設定し (「カスタムパラメーター」をご参照ください)、インストールを完了します。
ポリシータイプ
Kyverno バージョン 1.15 では、いくつかの新しいポリシータイプが導入されています。詳細については、「ポリシータイプ」をご参照ください。
ポリシータイプ | 説明 |
|
|
| Kubernetes リソースまたはワークロードテンプレートを検証します。ネイティブの |
| Kubernetes リソースまたはワークロードテンプレートを変更します。ネイティブの |
| CEL 式に基づいて、指定された Kubernetes リソースを生成および同期します。 |
| クラスターまたは名前空間レベルで指定されたリソースをクリーンアップします。 |
| イメージ署名と証明を検証します。 |
本番環境への適用
障害ポリシーの設定
failurePolicyは、Kyverno への Webhook 呼び出しが失敗した場合に API サーバーがどのように動作するかを定義します。特定のセキュリティおよび O&M 要件に基づいてこのポリシーを設定してください。設定の詳細については、「セキュリティ vs. 運用性」をご参照ください。フェイルオープン：Webhook が失敗した場合でも API リクエストの続行を許可します。これにより、クラスターの可用性は維持されますが、セキュリティリスクをもたらす可能性があります。フェイルクローズ：Webhook が失敗した場合に API リクエストをブロックします。これにより、セキュリティは確保されますが、クラスターの運用が中断される可能性があります。
高可用性と可観測性の設定
高可用性デプロイメント：Kyverno を複数のレプリカで実行します。ポッドアンチアフィニティとトポロジースプレッド制約を組み合わせて、レプリカを異なるノードまたはアベイラビリティゾーンに分散させます。
リソース計画：Kyverno Pod のリソース
requestsとlimitsを明確に設定し、予測可能なパフォーマンスを確保します。モニタリングとアラート：Managed Service for Prometheus でモニタリングを有効にし、Pod のステータス、リソース使用率、Webhook のレイテンシー、エラー率などの主要なメトリクスを追跡します。その後、これらのメトリクスに対するアラートを設定し、潜在的な問題について通知を受け取るようにします。
高可用性に関するその他の推奨事項については、「高可用性」をご参照ください。