Kubernetes admission policies & セキュリティ 2026 — Kyverno (CNCF Graduated) / OPA Gatekeeper / VAP (CEL) / Falco / KubeArmor / Tetragon 徹底ガイド

プロローグ — 「admission コントローラを一つ入れれば全部止まる」という神話

2026 年のあるセキュリティレビュー会議。

新人 SRE「Pod Security Admission を有効にしたのに、なんで Kyverno も要るんですか？」 シニアセキュリティエンジニア「PSA は pod の 5 フィールドぐらいしか見ない。registry 強制も label 強制も mutate も PSA にはできない。」 新人「じゃあ OPA Gatekeeper で全部やればいいですか？」 シニア「Rego を学んで運用できる人いる？」 新人「じゃあ新しい Validating Admission Policy で…」 シニア「あれは CEL だから image registry の mutate はできない。決済クラスタは mutate が要る。」

この短い会話に 2026 年の K8s セキュリティの本質が詰まっている。単一のツールですべてのセキュリティ要件を満たす時代は終わった。 admit には admit、ランタイムにはランタイム、イメージにはイメージ — それぞれ別のツールが別の layer で動く。

この記事は、その全体地図を一度に整理する。CNCF Graduated になった Kyverno (2024.11)、Rego ベースの OPA Gatekeeper、k8s 1.30 で GA したビルトイン VAP (2024.4)、1.32 alpha の MAP、PSP を置き換えた PSA、ランタイムセキュリティの Falco / KubeArmor / Tetragon、イメージ署名の Sigstore / Connaisseur、スキャンの Trivy Operator、姿勢評価の Kubescape / kube-bench / kube-score、そして韓国・日本の大手 IT 企業の実例まで。

1 章 · 2026 年 K8s admission & セキュリティ地図 — 4 つの layer

まず全体像から。2026 年の Kubernetes セキュリティは 4 つの layer に分かれる。ツールを選ぶ前に「自分はどの layer の問題を解いているのか」を知ることが先。

誤解 1「Kyverno で全部できる」 — ランタイムは止められない。コンテナ内で shell が curl evil.com を呼んでも admission は見えない。 誤解 2「Falco があれば安全」 — admit を止めなければ遅すぎる。privileged pod が既に起動していれば Falco はアラートを上げるだけ。 誤解 3「PSA は PSP の後継だから PSA だけで十分」 — PSA は baseline/restricted の数フィールドしか見ない。registry 強制、label 強制、カスタムルールは PSA にはできない。

2026 年の標準スタックは次の形に収束している。

• Admission: PSA (baseline/restricted) + Kyverno または VAP (mutate が要れば Kyverno、単純な validate だけなら VAP)
• Runtime: Falco (広く採用) + Tetragon (eBPF 精度が要る場合)
• Image: Sigstore + Cosign (署名イメージ強制) + Trivy Operator (CVE スキャン)
• Posture: Kubescape または kube-bench (月 1 回以上の監査)

ここから各ツールを順番に見ていく。

2 章 · Kyverno — CNCF Graduated (2024.11), YAML ベースのポリシー

Kyverno は 2024 年 11 月に CNCF の Graduated プロジェクトに昇格した。Linkerd、Argo、Cilium と同じ 1 軍卒業プロジェクトの列に入ったということ。

Kyverno が他の admission コントローラと決定的に違う点は、ポリシーを独自 DSL ではなく Kubernetes マニフェスト (YAML) で書く こと。Rego (OPA) や CEL (VAP) のような新言語を学ぶ必要がない。K8s マニフェストを書ける人なら 30 分で最初のポリシーが書ける。

代表例 — すべての Pod に team ラベルを強制。

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-team-label
spec:
  validationFailureAction: Enforce
  rules:
    - name: check-team-label
      match:
        any:
          - resources:
              kinds: ["Pod"]
      validate:
        message: "Pod は 'team' ラベルが必須"
        pattern:
          metadata:
            labels:
              team: "?*"

Kyverno の 3 つの action。

1. validate — 検査のみ、admit ブロック。
2. mutate — admit 前にマニフェストを修正 (例: デフォルトラベル / リソース limit の自動注入)。
3. generate — 他のリソースを自動生成 (Namespace 作成時に NetworkPolicy を自動生成)。

特に mutate + generate は OPA Gatekeeper が長く苦手としていた領域で、Kyverno が優位を取った点。registry 自動変更、ConfigMap 自動配布、NetworkPolicy 自動生成など。

# Image registry を強制 mutate
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: rewrite-image-registry
spec:
  rules:
    - name: replace-dockerhub
      match:
        any:
          - resources:
              kinds: ["Pod"]
      mutate:
        foreach:
          - list: "request.object.spec.containers"
            patchStrategicMerge:
              spec:
                containers:
                  - name: "{{ element.name }}"
                    image: "{{ regex_replace_all('^docker.io/', element.image, 'mirror.corp.local/dockerhub/') }}"

運用観点での Kyverno の強み。

• policy report: ポリシー違反を K8s ネイティブリソース (PolicyReport) として記録。Grafana や kubectl で直接見られる。
• CLI: kyverno apply policy.yaml --resource pod.yaml でクラスタなしにポリシー検証。
• policy library: kyverno.io/policies に 100+ の検証済みポリシー (CIS, NIST, PSS baseline/restricted)。
• autogen: Deployment ポリシーを書くと ReplicaSet/Pod のポリシーを自動生成。

弱点。

• 複雑な cross-resource ポリシーは Rego より表現力が弱い (Kyverno 1.10+ の CEL 統合で一部解消)。
• mutate ポリシーが増えると admission latency が積み上がる (各 webhook 呼び出し 50〜200 ms)。

2026 年現在、Kyverno は OPA Gatekeeper を採用率で抜いたという報告が複数。CNCF アンケートでは「利用中の admission policy ツール」1 位。

3 章 · OPA Gatekeeper — Rego ベース、Kyverno 以前の標準

Open Policy Agent (OPA) は 2017 年に Styra が作った汎用ポリシーエンジン。Kubernetes に限らず、Envoy、Terraform、CI まで同じ Rego 言語でポリシーを書ける点が最大の強み。Gatekeeper はその OPA を K8s admission webhook に包んだコンポーネント。

Gatekeeper の核となる概念 2 つ。

1. ConstraintTemplate — Rego で書かれた再利用可能なポリシーロジック。
2. Constraint — そのテンプレートのインスタンス (具体パラメータ + 適用範囲)。

ConstraintTemplate の例 — pod に特定の label が必要。

apiVersion: templates.gatekeeper.sh/v1
kind: ConstraintTemplate
metadata:
  name: k8srequiredlabels
spec:
  crd:
    spec:
      names:
        kind: K8sRequiredLabels
      validation:
        openAPIV3Schema:
          type: object
          properties:
            labels:
              type: array
              items:
                type: string
  targets:
    - target: admission.k8s.gatekeeper.sh
      rego: |
        package k8srequiredlabels
        violation[{"msg": msg}] {
          required := input.parameters.labels
          provided := input.review.object.metadata.labels
          missing := required[_]
          not provided[missing]
          msg := sprintf("Missing required label: %v", [missing])
        }

そのテンプレートに対応する Constraint。

apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sRequiredLabels
metadata:
  name: pods-must-have-team
spec:
  match:
    kinds:
      - apiGroups: [""]
        kinds: ["Pod"]
  parameters:
    labels: ["team", "owner"]

Rego の強み。

• 宣言的、非手続的。1 行で cross-resource 条件 (例: 「同じ namespace に ServiceAccount があって RoleBinding もある」) も簡単に書ける。
• set / array 演算が非常に強力。深い JSON 構造の検証に最適。
• OPA 自体が K8s 外でも 使える。CI での Terraform plan 検証、Envoy での L7 認可判断など。

弱点。

• 学習コストが本当に高い。慣れるまで数週間。
• ConstraintTemplate / Constraint の 2 段階構造でマニフェストが長くなる。
• mutate が別コンポーネント (Gatekeeper Mutation, beta)。1 つのツールで完結しない。
• ポリシー結果を K8s ネイティブリソースで見るのが Kyverno より不自然 (audit log 中心)。

2026 年現在 Gatekeeper は Rego 資産が既に多い組織、Envoy / Terraform まで統合ポリシーを運用したい組織で維持される。新規採用は Kyverno と VAP に押されている。

4 章 · Validating Admission Policy (VAP) — k8s 1.30 GA (2024.4)、ビルトイン CEL

2024 年 4 月、Kubernetes 1.30 で Validating Admission Policy (VAP) が GA した。意味は大きい。

• ビルトイン。別途 webhook コンポーネントの設置不要。kube-apiserver が直接評価。
• CEL (Common Expression Language) ベース。Google 製の軽量表現言語で、gRPC / Envoy / IAM でも利用。
• webhook 呼び出しコスト 0。admission latency が外部 webhook よりはるかに短い。

最もシンプルな例 — Deployment の replicas が 5 未満なら拒否。

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionPolicy
metadata:
  name: deployment-replica-limit
spec:
  failurePolicy: Fail
  matchConstraints:
    resourceRules:
      - apiGroups: ["apps"]
        apiVersions: ["v1"]
        operations: ["CREATE", "UPDATE"]
        resources: ["deployments"]
  validations:
    - expression: "object.spec.replicas >= 5"
      message: "Deployment は最低 5 replicas が必要"

そして ValidatingAdmissionPolicyBinding でどこに適用するかを指定。

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionPolicyBinding
metadata:
  name: deployment-replica-limit-binding
spec:
  policyName: deployment-replica-limit
  validationActions: ["Deny"]
  matchResources:
    namespaceSelector:
      matchLabels:
        env: production

CEL の表現力は段階的に拡張中。1.30 GA 時点では単純比較が限界だったが、1.31〜1.32 で cross-resource lookup (paramRef, variables)、authorizer チェック、namespace metadata 参照まで可能になった。

# 少し複雑な例 — コンテナイメージが自社 registry から来ている必要がある
validations:
  - expression: |
      object.spec.containers.all(c, c.image.startsWith('registry.corp.local/'))
    message: "イメージは registry.corp.local/ から来る必要がある"

VAP の強み。

• ビルトイン、依存ゼロ。
• ポリシーが K8s リソース。GitOps 親和。
• CEL 評価が in-process で latency が小さい。
• failurePolicy / auditAnnotations / warnings など K8s ネイティブのセマンティクス。

弱点。

• validate only。mutate はできない (それは MAP の領域、次章)。
• cross-resource lookup が Rego より制限的。
• CEL も結局は新言語。Kyverno ほど敷居は低くない。
• ポリシーライブラリとエコシステムが Kyverno より浅い (2026 年時点)。

推奨パターン: 単純な validate (ラベル / フィールドの確認、単純比較) は VAP、複雑な cross-resource + mutate は Kyverno。1 つのクラスタで両方を併用するのが 2026 年の標準になりつつある。

5 章 · Mutating Admission Policy (MAP) — k8s 1.32 alpha (2024.12)

2024 年 12 月、Kubernetes 1.32 で Mutating Admission Policy (MAP) が alpha で入った。VAP の mutate 兄弟。まだ alpha なので production 推奨ではないが、2026 年内に beta / GA する可能性が高い。

MAP は 2 つの mutate 方式を提供する。

1. ApplyConfiguration — server-side apply の typed configuration オブジェクトを CEL で作りマージ。
2. JSON Patch — RFC 6902 の JSON Patch を CEL で生成。

ApplyConfiguration の例 — すべての Pod にデフォルト securityContext を強制。

apiVersion: admissionregistration.k8s.io/v1alpha1
kind: MutatingAdmissionPolicy
metadata:
  name: default-security-context
spec:
  matchConstraints:
    resourceRules:
      - apiGroups: [""]
        apiVersions: ["v1"]
        operations: ["CREATE"]
        resources: ["pods"]
  mutations:
    - patchType: ApplyConfiguration
      applyConfiguration:
        expression: |
          Object{
            spec: Object.spec{
              securityContext: Object.spec.securityContext{
                runAsNonRoot: true,
                seccompProfile: Object.spec.securityContext.seccompProfile{
                  type: "RuntimeDefault"
                }
              }
            }
          }

MAP が GA すると Kyverno の mutate 領域の一部もビルトインに移る可能性がある。ただし Kyverno の generate、policy report、library は依然として差別化ポイント。

2026 年の推奨: MAP は 1.33+ beta 安定化までは試験用、単純なデフォルト注入程度に試す。コアの mutate は Kyverno で。

6 章 · Pod Security Admission (PSA) — PSP を置き換えたビルトイン

Pod Security Policy (PSP) は 1.21 で deprecated、1.25 で削除された。その代わりに入ったのが Pod Security Admission (PSA)。1.23 で beta、1.25 から GA、2026 年現在ほぼすべてのクラスタでデフォルト有効。

PSA の 3 つの profile。

PSA の 3 つの mode。

• enforce — 違反時はブロック。
• audit — audit log だけに記録。
• warn — kubectl に警告のみ。

典型的な運用: 新規ネームスペースは warn=restricted, audit=restricted, enforce=baseline で開始。十分な時間が経ったら enforce=restricted へ強化。

apiVersion: v1
kind: Namespace
metadata:
  name: prod-payments
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/enforce-version: latest
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/warn: restricted

PSA が見るフィールドは狭い。hostPID, hostNetwork, privileged, runAsNonRoot, allowPrivilegeEscalation, seccompProfile, capabilities など PSS の定義済みフィールドだけ。つまり PSA は pod セキュリティのフロアを保証し、registry 強制 / ラベル強制 / カスタムポリシーは Kyverno や VAP が上に積む構造。

2026 年のコンセンサス: すべての prod ネームスペース = PSA restricted enforce + Kyverno / VAP のカスタムルール。

7 章 · Rego vs CEL vs Cedar — ポリシー言語比較

ポリシー言語自体を比較してみる。ツール選択は事実上、言語選択でもある。

Rego の 1 つの例。

violation[msg] {
  input.review.object.kind == "Pod"
  some i
  not input.review.object.spec.containers[i].securityContext.runAsNonRoot
  msg := sprintf("Container %v must runAsNonRoot", [input.review.object.spec.containers[i].name])
}

同じ意図の CEL。

object.spec.containers.exists(c, !c.securityContext.runAsNonRoot)

同じ意図の Cedar (ポリシー / リソースモデルが違うので 1:1 対応ではない)。

forbid (
  principal,
  action == K8s::Action::"CreatePod",
  resource is K8s::Pod
) when {
  resource.spec.containers.any(c, c.securityContext.runAsNonRoot == false)
};

Cedar の面白い点は **形式解析 (formal analysis) ** が可能なこと。ポリシー 2 つが矛盾するか、どの入力で許可されるかなどを SMT solver で証明できる。AWS IAM の新ポリシー言語として採用され、2026 年は Cedar-K8s 統合の PoC が増えているが、まだ mainstream ではない。

実務推奨。

• Rego 資産が多い / Envoy・TF まで統合: OPA Gatekeeper を維持。
• YAML だけで終わらせたい: Kyverno。
• ビルトイン + 軽量 validate: VAP (CEL)。
• AWS 中心 + ポリシーの形式性が重要: Cedar を K8s 外で部分採用。

8 章 · Falco — CNCF Graduated、ランタイムセキュリティの標準

Falco は Sysdig が作ったランタイムセキュリティエンジンで、2024 年に CNCF Graduated になった。admission が止められなかったすべて — コンテナ内で起きる syscall、file access、network IO — を見る。

Falco の動作原理: カーネルの syscall を kprobe (または eBPF probe) で hook して stream で受け、Falco rule でマッチ。

# falco_rules.yaml — コンテナ内で shell が起動したらアラート
- rule: Terminal shell in container
  desc: A shell was used as the entrypoint/exec point into a container
  condition: >
    spawned_process and container
    and shell_procs and proc.tty != 0
  output: >
    Shell in container (user=%user.name container=%container.name
    image=%container.image.repository)
  priority: NOTICE
  tags: [shell, container]

priority は NOTICE / WARNING / ERROR / CRITICAL に分かれ、output は stdout、syslog、gRPC、HTTP webhook、Slack、Loki などに送れる。

代表的な Falco ルール (デフォルトの falco-rules から)。

• 「Write below etc」 — /etc/ 配下に書き込み発生。
• 「Read sensitive file untrusted」 — /etc/shadow などの機密ファイル読み取り。
• 「Unexpected network outbound」 — コンテナが想定外の外部ホストへ connect。
• 「Mining process detected」 — 既知の cryptominer パターン。

運用観点。

• Falcosidekick: Falco イベントを Slack、PagerDuty、Loki、S3 など 50+ destination に fan-out するサイドキック。
• Falco Talon: アラート → 自動対応 (pod kill、network policy 適用など)。
• drift detection: コンテナイメージになかった新しいバイナリがコンテナ内で実行されるとアラート。

弱点。

• アラートのみ、ブロックはできない (Falco 自体は)。Tetragon や KubeArmor とは違い enforce ではなく detect 中心。
• syscall が多いワークロードでは負荷 (eBPF driver で一部緩和)。
• ルールチューニングなしでは false positive が多い — 最初の 2 週間はアラートの 90% がノイズの可能性。

2026 年推奨スタック: Falco (detect) + Tetragon / KubeArmor (enforce) + SIEM (Loki / Datadog) への fan-out。

9 章 · KubeArmor — CNCF Sandbox、eBPF + LSM ベースの enforce

KubeArmor は AccuKnox が主導するランタイムセキュリティツールで、CNCF Sandbox 段階。Falco との差別点は detect だけでなく enforce — eBPF と Linux Security Module (AppArmor, SELinux, BPF-LSM) を直接利用して syscall そのものをブロックできる。

KubeArmorPolicy の例 — 特定ワークロードで /etc/shadow の読み取りをブロック。

apiVersion: security.kubearmor.com/v1
kind: KubeArmorPolicy
metadata:
  name: block-shadow-read
  namespace: prod
spec:
  selector:
    matchLabels:
      app: payments
  file:
    matchPaths:
      - path: /etc/shadow
        readOnly: false
  action: Block

action: Audit / Block / Allow の 3 モード。Block はカーネル層でブロックしてプロセスに EPERM を返す。

KubeArmor の強み。

• enforce 可能。Falco のようにアラートだけでなく実際にブロック。
• LSM ベースなので回避が難しい。
• per-pod policy。K8s の selector でワークロード単位の異なるポリシー。
• policy discovery: 正常動作を学習してポリシーを自動提案するモードも存在。

弱点。

• Sandbox なのでエコシステムと安定性は Falco より薄い。
• LSM (特に BPF-LSM) が有効なカーネルが必要 (5.7+)。
• 誤ったポリシーが正常ワークロードを殺す可能性 — Audit モードで十分検証してから Block。

推奨パターン: Falco でアラート → KubeArmor で enforce。両者は競合ではなく補完。

10 章 · Cilium Tetragon — eBPF ベースの観察性 + セキュリティ

Tetragon は Isovalent (Cilium の会社、2023 年に Cisco が買収) が作った eBPF ベースのランタイムセキュリティ & 観察性ツール。Cilium の姉妹プロジェクトで同じ eBPF インフラを共有する。

Tetragon の差別化ポイント。

• kernel hook の深さ。tracepoint、kprobe、uprobe まで polymorphic に hook。
• process lineage。すべてのプロセスの親子関係を追跡 — 「この cryptominer はどの web リクエストから始まったか」に答えられる。
• enforce 可能。SIGKILL シグナル injection、override return value で syscall ブロック。
• observability が一級。イベントを JSON で stream — Grafana、ELK、Datadog にネイティブ統合。

TracingPolicy の例 — コンテナ内で /etc/passwd を開くことを追跡。

apiVersion: cilium.io/v1alpha1
kind: TracingPolicy
metadata:
  name: watch-passwd-open
spec:
  kprobes:
    - call: "fd_install"
      syscall: false
      args:
        - index: 0
          type: int
        - index: 1
          type: "file"
      selectors:
        - matchArgs:
            - index: 1
              operator: "Equal"
              values:
                - "/etc/passwd"
          matchActions:
            - action: Sigkill

このポリシーは /etc/passwd が open されたらそのプロセスを即座に kill。Falco の detect と KubeArmor の enforce を 1 つのツールにまとめた形。

2026 年現在の Tetragon は。

• Cilium を使う環境で自然に併用。CNI = Cilium のクラスタでは Tetragon 導入はほぼ無料。
• 高度な forensics。事後調査時に process tree が追跡可能なのが Falco より強い。
• Falco と併用も多い。Falco はルールライブラリが豊富、Tetragon はより深い hook。

弱点。

• 学習曲線が Falco より急。
• Cilium エコシステムを使っていないと導入動機が弱い。

11 章 · Sigstore Policy Controller + Connaisseur — 署名イメージ強制

イメージサプライチェーンセキュリティの核心: 何がクラスタに入るか。2026 年の標準は 2 つ — Sigstore (Linux Foundation 配下) の cosign 署名、そしてその署名を K8s で強制する admission コントローラ。

Sigstore エコシステム。

• cosign — コンテナイメージに署名 / 検証する CLI。
• fulcio — short-lived な署名証明書を発行 (CT log ベース)。
• rekor — すべての署名を記録する transparency log (immutable)。
• Sigstore Policy Controller — K8s admission で cosign 署名を検証。

最もシンプルな流れ。

# ビルドマシン (CI) で
cosign sign --yes ghcr.io/corp/api:v1.2.3

# または keyless (OIDC ベース)
COSIGN_EXPERIMENTAL=1 cosign sign --yes \
  --identity-token=$(cat /var/run/secrets/tokens/oidc) \
  ghcr.io/corp/api:v1.2.3

検証ポリシー (Sigstore Policy Controller)。

apiVersion: policy.sigstore.dev/v1beta1
kind: ClusterImagePolicy
metadata:
  name: signed-by-corp
spec:
  images:
    - glob: "ghcr.io/corp/**"
  authorities:
    - keyless:
        identities:
          - issuer: https://token.actions.githubusercontent.com
            subject: "https://github.com/corp/.*"

このポリシーが適用されたネームスペースでは、GitHub Actions の OIDC トークンで署名されたイメージだけが admit される。鍵管理なしでも (keyless) 可能なのが fulcio + rekor の魔法。

Connaisseur (SAP のオープンソース) は別の選択肢。署名イメージ + Notary v1/v2 + cosign + Docker Content Trust までマルチバックエンドをサポート。Sigstore Policy Controller が cosign 専用なら、Connaisseur はマルチバックエンド。

# Connaisseur config の一部
validators:
  - name: corp-cosign
    type: cosign
    trust_roots:
      - name: default
        key: |
          -----BEGIN PUBLIC KEY-----
          ...
          -----END PUBLIC KEY-----
policy:
  - pattern: "ghcr.io/corp/*:*"
    validator: corp-cosign

2026 年の推奨: OIDC keyless cosign + Sigstore Policy Controller が最もシンプル。マルチバックエンドや regulated 環境は Connaisseur。

12 章 · Trivy Operator — イメージスキャンの K8s ネイティブ統合

Aqua Security の Trivy は OSS CVE スキャナで最も広く使われているツール。Trivy Operator はその Trivy を K8s ネイティブに統合したコントローラ — クラスタ内のすべてのイメージ / リソースを定期的にスキャンし、結果を K8s リソース (VulnerabilityReport, ConfigAuditReport, ExposedSecretReport) として記録する。

# Trivy Operator インストール後に自動生成される VulnerabilityReport の例
apiVersion: aquasecurity.github.io/v1alpha1
kind: VulnerabilityReport
metadata:
  name: pod-api-deployment-565cd
  namespace: prod
report:
  artifact:
    repository: ghcr.io/corp/api
    tag: v1.2.3
  summary:
    criticalCount: 0
    highCount: 2
    mediumCount: 5
  vulnerabilities:
    - vulnerabilityID: CVE-2024-XXXXX
      severity: HIGH
      ...

このリソースを Grafana / Loki / Datadog に送ったり、Kyverno ポリシーで「Critical CVE のあるイメージは拒否」のような admit ポリシーに再利用できる。

スキャン対象。

• コンテナイメージ — ベース OS パッケージ + 言語パッケージ (npm, pip, go.mod, ...)。
• K8s リソース misconfig — Trivy 自体の K8s チェックルール。
• secrets — イメージやマニフェスト内の secret 漏洩。
• SBOM 生成 — CycloneDX, SPDX。

2026 年の推奨: CI のビルド時に Trivy スキャン + クラスタで Trivy Operator が継続スキャン + Kyverno で Critical CVE を拒否 の 3 段防御。

13 章 · Polaris / Goldilocks (Fairwinds) — リソース right-sizing

Fairwinds の 2 つのオープンソース。セキュリティというよりベストプラクティス自動化に近い。

Polaris は K8s マニフェストのベストプラクティス違反を見るツール。CPU / メモリ limit なし、runAsNonRoot 抜け、latest タグ使用など 100+ ルール。admission webhook モード、CI モード、ダッシュボードモードの 3 種類。

# polaris config の一部
checks:
  cpuLimitsMissing: warning
  memoryLimitsMissing: warning
  runAsRootAllowed: danger
  hostIPCSet: danger
  notReadOnlyRootFilesystem: warning

Goldilocks は VerticalPodAutoscaler の recommendation モードを使ってワークロード単位の 推奨 request / limit を自動計算しダッシュボードで表示する。「この deployment は CPU request 50m まで下げてよい」といった推奨。

# Goldilocks インストール (helm)
helm install goldilocks fairwinds-stable/goldilocks --namespace goldilocks
# モニタするネームスペースをラベリング
kubectl label ns prod goldilocks.fairwinds.com/enabled=true

両方とも直接のセキュリティではないが、misconfig がセキュリティ事故の 60% 以上 という統計を考えるとセキュリティスタックの一部。

14 章 · Kubescape (ARMO) — セキュリティ姿勢評価

Kubescape は ARMO が作った (現在 CNCF Incubating、2023 年昇格) セキュリティ姿勢評価ツール。NSA-CISA Kubernetes Hardening Guidance、MITRE ATT&CK、CIS Kubernetes Benchmark などのフレームワークでクラスタを評価する。

# クラスタを NSA フレームワークでスキャン
kubescape scan framework nsa

# 結果例
# Control: C-0007 Data Destruction
# Resources: 23
# Compliance Score: 87.5%
# Failed: 3 resources
# ...

特徴。

• 多様なフレームワーク — NSA, MITRE, CIS, ArmoBest, AllControls。
• IDE 統合 — VS Code 拡張でマニフェスト作成中にも評価。
• GitOps 親和 — kubescape scan を CI に入れて PR 段階でブロック。
• ホスト型 SaaS (ARMO Platform) と OSS CLI の両方が存在。

Kubescape が他ツールと違う点: end-to-end 評価。admission だけ、ランタイムだけではなく、RBAC、network policy、image、configuration まで一度に見る。

# 単一ワークロードだけスキャン
kubescape scan workload deployment/api -n prod

# YAML ファイルを直接スキャン (CI 用)
kubescape scan ./manifests/*.yaml

15 章 · kube-bench / kube-hunter / kube-score / Checkov K8s — 補助ツール群

最後によく一緒に使われる補助ツール 4 つ。

kube-bench (Aqua Security) — CIS Kubernetes Benchmark を実行する。control plane ノード、etcd、kubelet、policies まで約 200 個のチェック。

# kube-bench をノード上の Job として実行
kubectl apply -f https://raw.githubusercontent.com/aquasecurity/kube-bench/main/job.yaml
kubectl logs -l job-name=kube-bench

# 出力例
# [PASS] 1.1.1 Ensure that the API server pod specification file ...
# [FAIL] 1.2.10 Ensure that the admission control plugin EventRateLimit is set
# ...

EKS / AKS / GKE 専用の派生もある (eks-bench, etc.)。

kube-hunter (Aqua) — クラスタを外部 (あるいは内部) から能動的に hunt する。pen-testing ツール。「この etcd が認証なしで露出している」のような active discovery。

kube-hunter --remote 10.0.0.1
# Hunters Active: 17
# Vulnerabilities found:
# 1) Pod Has Privileged Access in container some-pod
# ...

kube-score — シンプルなマニフェスト静的解析。スコアをつける。

kube-score score deployment.yaml
# apps/v1/Deployment my-app
#     [CRITICAL] Container Image Pull Policy
#       - my-app -> ImagePullPolicy is not set
#     [WARNING] Container Resources
#       - my-app -> CPU limit is not set

CI に入れやすいツール。

Checkov (Bridgecrew → Palo Alto) — IaC 静的解析の広域版。Terraform、CloudFormation、K8s、Helm、Kustomize、Dockerfile など。K8s マニフェストも 800+ ポリシーで検査。

checkov -d ./manifests --framework kubernetes
# Passed checks: 145, Failed checks: 12
# CKV_K8S_8: "Liveness Probe Should be Configured"
# ...

推奨利用シーン。

• kube-bench: クラスタセットアップ直後に 1 回、その後四半期ごと。
• kube-hunter: 新クラスタ導入時に red team 風に。
• kube-score: CI のマニフェスト PR 段階。
• Checkov: IaC 全般の統合ゲート (TF + K8s + Docker まで)。

16 章 · 韓国 / 日本の K8s セキュリティ — Toss / Kakao / メルカリ

最後に韓国・日本の大手 IT が K8s セキュリティをどうしているか。(公開カンファレンス発表 / ブログベース)

Toss

Toss は決済ドメインの特性上 PCI-DSS が強く適用される。K8s セキュリティスタック。

• PSA restricted enforce がすべての prod ネームスペースのデフォルト。
• 多数の Kyverno ポリシー — イメージ registry 強制、label / owner 強制、NetworkPolicy 自動生成。
• 社内 admission webhook — Kyverno で扱えないドメインポリシー (決済サービスの特定 Helm チャート検証など) は自社 webhook。
• Falco + Loki + Grafana — ランタイムアラートスタック。
• イメージ署名 — 社内 CI が cosign で署名し、Sigstore Policy Controller で強制。
• Trivy Operator — 毎日 CVE スキャン、結果を社内セキュリティダッシュボードへ送信。

SLASH などの Toss カンファレンスで「Kyverno マイグレーション」「PSA 導入記」発表が増えている。

Kakao

Kakao はグループ会社単位で K8s が分散していて、Kakao Enterprise が作る社内プラットフォーム (DKOS、Kubeflow 由来など) 中心。公開された if(kakao) 発表から。

• OPA Gatekeeper がいまだに多く使われる — 社内 Rego 資産が多く、Envoy / IaC まで統合。
• 新規サービスでは Kyverno 採用が増加。
• Falco、kube-bench も標準。
• Kakao Enterprise の一部 SaaS は Kubescape で定期監査。

メルカリ (Mercari)

メルカリは GCP 中心だが K8s セキュリティスタックは非常に進んでいる。

• Sigstore + cosign + Sigstore Policy Controller を早期導入。メルカリエンジニアリングブログに keyless signing 導入記の記事がある。
• Kyverno が標準 admission。GKE の PSA と併用。
• Falco + GKE の Container Threat Detection を並列運用。
• Trivy がビルド / ランタイム両方で。

LINE / Yahoo Japan

LINE はグローバルトラフィックの特性で自社セキュリティプラットフォームが存在。K8s 部分だけ見ると OPA と Kyverno が混在、Falco がランタイム。Yahoo Japan も似た構成。

共通パターン

3 社に共通すること。

• PSA はフロア、その上に Kyverno (または OPA) でカスタム。
• ランタイムは Falco が最多、Tetragon は Cilium CNI を使う場所で併用。
• イメージ署名は cosign に収束しつつある。
• Trivy が CVE 標準。

2026 年の韓国・日本市場のトレンド: 単一ツールでの統合よりも、layer ごとに適切なツールのスタック構成が標準になっている。

17 章 · 誰が何を選ぶべきか — シナリオ別推奨

最後に 1 ページの決定表。

運用観点で忘れてはならないこと。

• dry-run から。新しいポリシーは enforce ではなく audit / warn モードで 1〜2 週間。
• ポリシーもコード。GitOps (Argo / Flux) で管理、PR レビュー必須。
• アラート疲れ注意。Falco ルールを最初から全開で点けると 90% がノイズ。1 週間チューニングしてから enforce。
• drift detection。クラスタの実際のポリシー != Git のポリシー になった瞬間にセキュリティは崩れる。
• イメージ署名はサプライチェーンの 80%。SLSA フレームワークと一緒に。

エピローグ — セキュリティはツールではなく layer の合奏だ

2026 年の K8s セキュリティの真の教訓はツールではなく 合奏 だ。admission が止め、ランタイムが見て、イメージが検証され、posture が定期的に評価される。どれか一つの layer だけ点けるとどれか一つの layer が空になる。

ツールは変わる。5 年前は PSP を運用していた人が今日は PSA + Kyverno + VAP を運用し、来年は MAP まで運用するかもしれない。しかし layer の意味を理解しているチームはツールが変わっても生き残る。1 つのツールに依存しているチームはそのツールが deprecated になる瞬間 (Datree のように 2023 年 sunset) 崩壊する。

次回候補: Cosign と SLSA — サプライチェーンセキュリティの本当の深さ、Kyverno ポリシーライブラリ 100 選 — production にそのまま使えるポリシー、Tetragon process tree forensics — 事後調査で cryptominer を追跡する。

「セキュリティは admission だけではない。admission だけ点ければ admit された後のすべてが無防備だ。」

— K8s admission policies & セキュリティ 2026、おわり。

参考 / References

• Kyverno — CNCF Graduated announcement (Nov 2024)
• Kyverno Documentation
• Kyverno Policies Library
• Kyverno GitHub — kyverno/kyverno
• OPA Gatekeeper Documentation
• Open Policy Agent
• Rego Language Reference
• Kubernetes 1.30 release notes — VAP GA
• Validating Admission Policy Documentation
• Kubernetes 1.32 — Mutating Admission Policy alpha
• Mutating Admission Policy Documentation
• Pod Security Admission Documentation
• Pod Security Standards
• CEL — Common Expression Language
• Cedar Policy Language
• Falco — CNCF Graduated
• Falco GitHub — falcosecurity/falco
• Falcosidekick
• KubeArmor Documentation
• KubeArmor GitHub — kubearmor/KubeArmor
• Cilium Tetragon
• Tetragon GitHub — cilium/tetragon
• Sigstore Project
• Cosign Documentation
• Sigstore Policy Controller
• Connaisseur GitHub — sse-secure-systems/connaisseur
• Trivy Documentation
• Trivy Operator
• Polaris (Fairwinds)
• Goldilocks (Fairwinds)
• Kubescape (ARMO)
• ARMO Platform
• kube-bench
• CIS Kubernetes Benchmark
• kube-hunter
• kube-score
• Checkov
• Datree sunset announcement (2023)
• Toss SLASH conference
• if(kakao) developers conference
• Mercari Engineering Blog
• NSA-CISA Kubernetes Hardening Guidance
• SLSA Framework