LabHub

ブログ

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

2026-05-16 · 33 分で読めます · #kubernetes#security#admission-controller#kyverno#opa-gatekeeper#rego#cedar#validating-admission-policy#cel#pod-security-admission#falco#kubearmor#cilium-tetragon#ebpf#sigstore#cosign#connaisseur#trivy-operator#polaris#goldilocks#kubescape#armo#kube-bench#kube-hunter#checkov#deep-dive#japanese

한국어English日本語

プロローグ — 「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 の問題を解いているのか」を知ることが先。

Layerタイミング代表ツール主な問い
Admission (ポリシーゲート)API server リクエスト時Kyverno, OPA Gatekeeper, VAP, MAP, PSA「このマニフェストを admit するか？」
Runtime (実行時)コンテナ起動後Falco, KubeArmor, Tetragon「このプロセス / syscall は正常か？」
Image / Supply chainビルドからデプロイまでSigstore Policy Controller, Connaisseur, Trivy Operator「このイメージを信用してよいか？」
Posture / Audit定期評価Kubescape, kube-bench, Polaris, Checkov「クラスタは安全な状態か？」

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

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

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

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 の強み。

弱点。

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 の強み。

弱点。

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 した。意味は大きい。

最もシンプルな例 — 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 の強み。

弱点。

推奨パターン: 単純な 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。

Profile説明
privileged制限なし。システムワークロード用
baseline既知の権限昇格をブロック。一般ワークロード
restrictedhardened、PSS の中で最も厳格

PSA の 3 つの mode。

典型的な運用: 新規ネームスペースは 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 — ポリシー言語比較

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

言語出自パラダイム強み弱み
RegoOPA (CNCF)宣言的、datalog 系表現力、汎用性 (K8s 外も Envoy / TF)学習曲線が急
CELGoogle型付き expression、eager 評価軽量、低 latency、K8s ビルトインmutate 表現が長くなる、cross-resource 制限
CedarAWS (2023 公開)型付き、形式検証可、ABAC形式解析が可能、IAM スタイルK8s 統合がまだ薄い
Kyverno YAMLNirmata → CNCFマニフェスト自体がポリシー敷居が一番低い表現力に限界

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 ではない。

実務推奨。

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 から)。

運用観点。

弱点。

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 の強み。

弱点。

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

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

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

Tetragon の差別化ポイント。

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 は。

弱点。

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

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

Sigstore エコシステム。

最もシンプルな流れ。

# ビルドマシン (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 ポリシーに再利用できる。

スキャン対象。

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
# ...

特徴。

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"
# ...

推奨利用シーン。

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

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

Toss

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

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

Kakao

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

メルカリ (Mercari)

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

LINE / Yahoo Japan

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

共通パターン

3 社に共通すること。

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

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

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

シナリオAdmissionRuntimeImagePosture
小規模 (10 ノード未満)、すぐ立ち上げPSA + KyvernoFalcoTrivy CI のみkube-bench 四半期
中規模 prod (数十〜数百ノード)PSA + Kyverno + VAPFalco + Tetragoncosign + Sigstore PCKubescape 月次
エンタープライズ、マルチクラスタPSA + Kyverno + 社内 webhookFalco + KubeArmor or Tetragoncosign + Sigstore PC or ConnaisseurKubescape + kube-bench
金融 / Regulated (PCI / HIPAA)PSA restricted + Kyverno + OPAFalco + KubeArmorConnaisseur (マルチバックエンド)Kubescape + kube-bench + Checkov
OPA / Rego 資産が多いOPA Gatekeeper 維持 + VAP で単純ルールFalcocosignkube-bench
Cilium CNI 使用中Kyverno or VAPTetragoncosignKubescape

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

エピローグ — セキュリティはツールではなく 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

原文を読む: https://www.youngju.dev/blog/culture/2026-05-16-kubernetes-admission-policies-security-2026-kyverno-opa-gatekeeper-vap-falco-kubearmor-deep-dive.ja

コメント

まだコメントはありません。

ログインするとコメントできます