KyvernoとFalcoによるKubernetesアドミッションポリシーとランタイム防御

イメージスキャンと脅威モデリングはデプロイ前を守ります。アドミッションポリシーはワークロードがクラスタに入る瞬間（moment of truth）を守ります。ランタイムモニターはその後に起こるすべてを記録する監視カメラです。

クラスタ内の3つの防御レイヤー

レイヤー	役割	ツール
プリアドミッション	Lint、イメージスキャン、署名検証	Trivy、Cosign
アドミッション	ポリシー違反のワークロードをブロック	Kyverno、OPA Gatekeeper
ランタイム	異常な挙動の検知、ネットワークポリシー	Falco、Cilium Tetragon、NetworkPolicy

Kyverno vs OPA Gatekeeper——どちらを選ぶか？

Kyverno：純粋なYAMLでポリシーを記述でき、短く、学習が容易。Mutate、Generate、verifyImagesキーレスをサポート。多くのケースに適しています。
OPA Gatekeeper：Regoで記述し、複雑なロジックに強力。OPAエコシステム（APIゲートウェイ、マイクロサービス認可）が既にある場合に適しています。

推奨：新しいクラスタはKyvernoから始めましょう。ポリシーは宣言的なので、後から両者間で移行するのは難しくありません。

用意すべきベースラインポリシー

アプリ用ネームスペースにPod Security Standards: restrictedを適用。
privileged: true、hostNetwork、hostPIDで実行されるPodをブロック。
イメージは社内レジストリ（許可リスト）からのみ要求。
すべてのコンテナにresources.requests/limitsを要求。
標準ラベル（team、env、cost-center）をコスト追跡とIRのために要求。
本番イメージのCosign署名を検証。

安全な展開：Audit → Fix → Enforce

稼働中のクラスタに対して、いきなりvalidationFailureAction: Enforceを適用してはいけません。参考プロセス：

validationFailureAction: Auditでポリシーを適用。
1〜2週間、Kyverno PolicyReport CRDで違反を測定。
違反した各ワークロードに対し、オーナー付きの修正チケットを作成。
ステージング環境で違反が0になったら、dev → staging → prodの順にEnforceに切り替え。

明確な例外プロセスを用意しましょう：特殊なワークロード（特権デバッグPodなど）には、理由・有効期限・オーナーを記載したアノテーションを必須にします。

デフォルト拒否のネットワークポリシー

各アプリ用ネームスペースは「すべて拒否」ポリシーから始め、実際の要件に応じて段階的に開放しましょう：

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: payments
spec:
  podSelector: {}
  policyTypes: ["Ingress", "Egress"]

その後、必要な接続を1つずつ開放します：アプリ → DB、アプリ → サービスメッシュ、外部APIへのエグレスはエグレスゲートウェイ経由など。Ciliumを使えばL7（HTTPパス、gRPCメソッド、Kafkaトピック）でのポリシーが可能で、ポート/IPだけよりはるかに強力です。

Falco：コンテナのランタイム検知

Falcoはカーネル（eBPFまたはカーネルモジュール）にフックしてシステムコールを観察します。最も価値のあるルールの一例：

コンテナ内シェル：shell_in_container。本番環境でシェルが正当な理由を持つことは稀です。
ランタイムイメージ内のバイナリファイル改変（侵害の兆候）。
許可リスト外のIP/ドメインへの異常な外向き接続。
/etc/shadowやkubeconfigなど機密ファイルの読み取り。
/var/run/docker.sockや/procなどの機密パスのマウント。

高重要度ルールのFalcoイベントはSlack/PagerDutyへ、その後の分析用にはSIEMへストリームしましょう。

Cilium Tetragon：ハードウェア支援、低オーバーヘッド

TetragonもeBPFを使いますが、大規模クラスタ向けに性能が最適化されており、検知だけでなく強制（enforce）も可能です（例：違反するシステムコール時にプロセスをkill）。インカーネルでの応答時間が必要な場合に適しています。

アラートが鳴ったら——簡潔なIRワークフロー

15分以内にトリアージ：重要度に応じて真陽性/偽陽性を分類。
NetworkPolicyでPodを隔離してエグレスをブロック。すぐに削除しないこと（証拠が失われる）。
スナップショットを取得：kubectl debug、メモリダンプ、ログコピー、監査証跡のエクスポート。
Podがアクセスできた可能性のあるクレデンシャル（ServiceAccountトークン、シークレットマウント）をローテーション。
調査後：blamelessなポストモーテムを書き、必要なら新しいFalcoルールを追加。

結論

Kubernetesの保護はRBACとファイアウォールだけではありません。3つのレイヤーが必要です：プリアドミッション（イメージスキャン、署名）、アドミッション（Kyverno）、ランタイム（Falco/Tetragon、NetworkPolicy）。Auditモードのベースラインポリシーから始めて段階的にEnforceし、FalcoをSIEMと組み合わせる——これが2026年の本番クラスタの大半に十分なほど堅牢な構成です。