💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

원문 렌더가 준비되기 전까지 텍스트 가이드로 표시합니다.

プロローグ — 「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:

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:

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:

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:

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:

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:

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:

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。

| Profile | 説明 |

| --- | --- |

| privileged | 制限なし。システムワークロード用 |

| baseline | 既知の権限昇格をブロック。一般ワークロード |

| restricted | hardened、PSS の中で最も厳格 |

PSA の 3 つの mode。

- **enforce** — 違反時はブロック。

- **audit** — audit log だけに記録。

- **warn** — kubectl に警告のみ。

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

apiVersion: v1

kind: Namespace

metadata:

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:

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:

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:

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:

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)](https://www.cncf.io/announcements/2024/11/12/cloud-native-computing-foundation-announces-the-graduation-of-kyverno/)

- [Kyverno Documentation](https://kyverno.io/docs/)

- [Kyverno Policies Library](https://kyverno.io/policies/)

- [Kyverno GitHub — kyverno/kyverno](https://github.com/kyverno/kyverno)

- [OPA Gatekeeper Documentation](https://open-policy-agent.github.io/gatekeeper/website/docs/)

- [Open Policy Agent](https://www.openpolicyagent.org/)

- [Rego Language Reference](https://www.openpolicyagent.org/docs/latest/policy-language/)

- [Kubernetes 1.30 release notes — VAP GA](https://kubernetes.io/blog/2024/04/17/kubernetes-v1-30-release/)

- [Validating Admission Policy Documentation](https://kubernetes.io/docs/reference/access-authn-authz/validating-admission-policy/)

- [Kubernetes 1.32 — Mutating Admission Policy alpha](https://kubernetes.io/blog/2024/12/11/kubernetes-v1-32-release/)

- [Mutating Admission Policy Documentation](https://kubernetes.io/docs/reference/access-authn-authz/mutating-admission-policy/)

- [Pod Security Admission Documentation](https://kubernetes.io/docs/concepts/security/pod-security-admission/)

- [Pod Security Standards](https://kubernetes.io/docs/concepts/security/pod-security-standards/)

- [CEL — Common Expression Language](https://github.com/google/cel-spec)

- [Cedar Policy Language](https://www.cedarpolicy.com/)

- [Falco — CNCF Graduated](https://falco.org/)

- [Falco GitHub — falcosecurity/falco](https://github.com/falcosecurity/falco)

- [Falcosidekick](https://github.com/falcosecurity/falcosidekick)

- [KubeArmor Documentation](https://kubearmor.io/)

- [KubeArmor GitHub — kubearmor/KubeArmor](https://github.com/kubearmor/KubeArmor)

- [Cilium Tetragon](https://tetragon.io/)

- [Tetragon GitHub — cilium/tetragon](https://github.com/cilium/tetragon)

- [Sigstore Project](https://www.sigstore.dev/)

- [Cosign Documentation](https://docs.sigstore.dev/cosign/overview/)

- [Sigstore Policy Controller](https://docs.sigstore.dev/policy-controller/overview/)

- [Connaisseur GitHub — sse-secure-systems/connaisseur](https://github.com/sse-secure-systems/connaisseur)

- [Trivy Documentation](https://aquasecurity.github.io/trivy/)

- [Trivy Operator](https://aquasecurity.github.io/trivy-operator/)

- [Polaris (Fairwinds)](https://polaris.docs.fairwinds.com/)

- [Goldilocks (Fairwinds)](https://goldilocks.docs.fairwinds.com/)

- [Kubescape (ARMO)](https://kubescape.io/)

- [ARMO Platform](https://www.armosec.io/)

- [kube-bench](https://github.com/aquasecurity/kube-bench)

- [CIS Kubernetes Benchmark](https://www.cisecurity.org/benchmark/kubernetes)

- [kube-hunter](https://github.com/aquasecurity/kube-hunter)

- [kube-score](https://kube-score.com/)

- [Checkov](https://www.checkov.io/)

- [Datree sunset announcement (2023)](https://www.datree.io/)

- [Toss SLASH conference](https://toss.tech/slash)

- [if(kakao) developers conference](https://if.kakao.com/)

- [Mercari Engineering Blog](https://engineering.mercari.com/en/blog/)

- [NSA-CISA Kubernetes Hardening Guidance](https://www.cisa.gov/news-events/cybersecurity-advisories/aa22-238a)

- [SLSA Framework](https://slsa.dev/)