クラスターに「ルール」がなかったらどうなるか？
Kubernetesの運用を始めた当初、私はRBAC（ロールベースアクセス制御）さえあればシステムを守れると信じていました。しかし、現実はそう甘くありませんでした。開発者はデプロイを急ぐあまり、意図せずコンテナをroot権限で実行したり、CPUやメモリの制限（Resource Limits）を忘れたりすることがよくあります。ある時、リソース制限のないサービスがノードの全リソースを使い果たし、他の重要なサービスが次々とハングアップしてしまいました。
手動でエラーをチェックしたり一人一人に注意したりする代わりに、私はKyvernoを使ってこのプロセスを自動化することにしました。KyvernoはKubernetes専用に設計されたポリシーエンジンです。クラスターに投入されるすべてのリソースを監視する「警察官」のような役割を果たします。基準を満たさないリソースはブロックされるか、正しい設定に自動修正されます。
Kyvernoの最大の魅力は、YAMLを使用することです。Kubernetesのマニフェストファイルに慣れているなら、15分もあればKyvernoを使いこなせるようになるでしょう。OPA（Open Policy Agent）のように複雑なRego言語を学習する必要はありません。
5分で完了：Kyvernoのインストールと試用
Kyvernoをデプロイする最も速い方法はHelmを使用することです。ターミナルで数行のコマンドを実行するだけです。
# KyvernoのHelmリポジトリを追加
helm repo add kyverno https://kyverno.github.io/kyverno/
# リポジトリを更新してインストール
helm repo update
helm install kyverno kyverno/kyverno -n kyverno --create-namespace実際のポリシーを作成してみましょう：「すべてのPodに ‘owner’ ラベルを必須にする」。このラベルがあれば、トラブル発生時に誰がそのリソースに責任を持つのかをすぐに特定できます。
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
name: require-owner-label
spec:
validationFailureAction: Enforce
rules:
- name: check-for-owner-label
match:
any:
- resources:
kinds:
- Pod
validate:
message: "エラー：Podの管理者を特定するために 'owner' ラベルを追加する必要があります。"
pattern:
metadata:
labels:
owner: "?*"kubectl apply -f policy.yaml で適用した後、owner ラベルのないPodを作成しようとすると、すぐにエラーメッセージが表示されます。システムはAPIサーバーの入り口でそのリクエストを拒否します。
3つの強力な機能：Validate、Mutate、Generate
Kyvernoは単に禁止するだけではありません。特定の課題に対して3つの柔軟な処理メカニズムを提供します。
1. Validate – 厳格なゲートキーパー
これは最も一般的な機能です。基準を定義し、Kyvernoがリソースがそれに適合しているかチェックします。例えば、物理ノードの制御権を奪われるリスクを避けるため、コンテナの privileged（特権）モードでの実行を禁止できます。
ログに警告を記録する Audit モードか、違反を即座にブロックする Enforce モードを選択できます。
2. Mutate – 設定の自動「パッチ当て」
この機能は開発者をサポートする上で非常に便利です。例えば、チームが imagePullPolicy: Always の設定を忘れがちだとします。修正を強いる代わりに、KyvernoがPod作成前にこの設定をYAMLファイルに自動挿入します。
設計図の足りない部分を黙って補ってくれる執事のような存在です。
3. Generate – インフラの自動生成
プロジェクト用に新しいNamespaceを作成するたびに、NetworkPolicy、ResourceQuota、Secretなどを作成する必要があります。Kyvernoは新しいNamespaceの作成を検知すると、これらのリソースを自動的に「生成」します。
機密性の高いSecretについては、私はよくToolcraft의 パスワードジェネレーターを使って安全な文字列を生成しています。これはクライアントサイドで完結するため、K8s Secretにコピーする際も安心です。
Pod Security Standards (PSS) を「痛みなく」導入する
Kubernetesは、Privileged、Baseline、Restrictedの3つのレベルからなるセキュリティ標準「PSS」を定義しています。これらを適用することで、SOC2やPCI-DSSなどのセキュリティ監査に合格しやすくなります。
KyvernoにはPSS用のポリシーライブラリが用意されています。Production環境で Restricted レベルを有効にするだけで、hostPathへのアクセスの禁止や、読み取り専用（read-only）ルートファイルシステムの強制といった項目を自動でチェックできます。
アドバイス： 初めて導入する場合は、1〜2週間ほど Audit モードで運用してください。レポートを監視して、既存のPodがどれくらい違反しているかを確認してから Enforce に切り替えましょう。これにより、システム全体が突然停止するトラブルを防げます。
Kyvernoをスムーズに運用するための実践的ノウハウ
大規模なシステムに導入した経験から、4つの重要な注意点をまとめました。
- システムNamespaceを除外する：
kube-systemやkyverno自身のNamespaceは必ず除外（exclude）設定に含めてください。ポリシーが厳しすぎてCoreDNSなどを誤ってブロックしてしまうと、クラスターは数分で「崩壊」します。 - パフォーマンスの監視： KyvernoはWebhookを通じてAdmission Requestを処理します。各リクエストには通常10〜30msのレイテンシが加わります。数百のポリシーがある場合は、Kyverno Podのリソース（CPU/RAM）を増やしてください。
- ローカルでの徹底テスト： 本番クラスターにデプロイする前に、CI/CDパイプラインで Kyverno CLI の
kyverno testコマンドを使用してポリシーを検証してください。 - Mutateを乱用しない： 設定の自動修正をやりすぎると、実際の動作が書いたYAMLと異なるため開発者が混乱します。常にドキュメントをセットで用意しましょう。
Kyvernoのおかげで、初歩的な設定ミスを80%削減し、システムのセキュリティを向上させることができました。これは単なるツールではなく、プロフェッショナルに Policy as Code を実践するための手法です。Kubernetesを運用しているなら、ぜひ今日からKyvernoを導入して、より安らかな夜を過ごしましょう。
