Kubernetes Admission Policies & Security 2026 — Kyverno (CNCF Graduated) / OPA Gatekeeper / VAP (CEL) / Falco / KubeArmor / Tetragon Deep Dive

Prologue — The myth that "one admission controller blocks everything"

A 2026 security review meeting.

Junior SRE: "We turned on Pod Security Admission. Why do we still need Kyverno?" Senior security engineer: "PSA only looks at about five pod fields. Forcing a registry, forcing labels, doing mutate — PSA cannot do any of that." Junior: "Then can we just do everything with OPA Gatekeeper?" Senior: "Do you have anyone who can learn and operate Rego?" Junior: "Then the new Validating Admission Policy..." Senior: "That is CEL, so it cannot mutate image registries. Our payments cluster needs mutate."

That short dialogue captures the essence of 2026 K8s security. The era of a single tool satisfying every security requirement is over. Admission has its layer, runtime has its layer, images have their layer — each requires a different tool at a different layer.

This article maps the whole topology in one pass. CNCF Graduated Kyverno (Nov 2024), Rego-based OPA Gatekeeper, the built-in VAP that hit GA in k8s 1.30 (Apr 2024), MAP alpha in 1.32, PSA replacing PSP, runtime security with Falco / KubeArmor / Tetragon, image signing with Sigstore / Connaisseur, scanning with Trivy Operator, posture evaluation with Kubescape / kube-bench / kube-score, and what Korean and Japanese big tech actually use.

1. The 2026 K8s admission & security map — split across four layers

The big picture first. K8s security in 2026 divides into four layers. Before picking a tool, you must know which layer your problem lives in.

Misconception 1: "Kyverno covers everything." Wrong — admission cannot block runtime behavior. A shell inside a container calling curl evil.com is invisible to admission. Misconception 2: "Falco keeps us safe." Wrong — if admission did not block, you are already too late. A privileged pod is already running, and Falco only fires an alert. Misconception 3: "PSA is the PSP successor, so PSA alone is enough." Wrong — PSA looks at roughly five baseline/restricted fields. Registry enforcement, label enforcement, custom rules — PSA does none of that.

In 2026 the standard stack converges to this shape.

• Admission: PSA (baseline/restricted) + Kyverno or VAP (Kyverno if you need mutate, VAP if pure validate is enough)
• Runtime: Falco (widely adopted) + Tetragon (when eBPF precision matters)
• Image: Sigstore + Cosign (signed image enforcement) + Trivy Operator (CVE scanning)
• Posture: Kubescape or kube-bench (audited at least monthly)

Let us go tool by tool.

2. Kyverno — CNCF Graduated (Nov 2024), YAML-based policy

Kyverno was promoted to Graduated CNCF status in November 2024. That puts it in the same tier as Linkerd, Argo, and Cilium — the first-class graduate ranks.

What sets Kyverno apart from other admission controllers: policies are written as plain Kubernetes manifests (YAML), not as a separate DSL. No need to learn Rego (OPA) or CEL (VAP). If you already write K8s manifests, you can write your first policy in 30 minutes.

The canonical example — require a team label on every Pod.

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: "Pods must have a 'team' label"
        pattern:
          metadata:
            labels:
              team: "?*"

Kyverno's three actions.

1. validate — inspect only, block admission.
2. mutate — modify the manifest before admit (e.g., inject default labels or resource limits).
3. generate — auto-create related resources (e.g., generate a NetworkPolicy when a Namespace is created).

mutate + generate is the area where OPA Gatekeeper struggled for years, which is why Kyverno has been winning ground. Auto-rewrite registries, push ConfigMaps automatically, generate NetworkPolicies — all easy.

# Force image registry via 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/') }}"

Operational strengths.

• policy report: violations are recorded as native K8s resources (PolicyReport). Read from Grafana, kubectl, anywhere.
• CLI: kyverno apply policy.yaml --resource pod.yaml lets you validate offline, no cluster needed.
• policy library: 100+ vetted policies at kyverno.io/policies (CIS, NIST, PSS baseline/restricted).
• autogen: write a Deployment policy and Kyverno generates the ReplicaSet/Pod variants.

Weaknesses.

• Complex cross-resource policies are less expressive than Rego (partially addressed by Kyverno 1.10+ CEL integration).
• Many mutate policies accumulate admission latency (50–200 ms per webhook call).

In 2026 multiple surveys report Kyverno has overtaken OPA Gatekeeper by adoption. It tops the CNCF "admission policy tool in use" list.

3. OPA Gatekeeper — Rego-based, the pre-Kyverno standard

Open Policy Agent (OPA), created by Styra in 2017, is a general-purpose policy engine. Its big advantage is that the same Rego language drives policies for Kubernetes, Envoy, Terraform, CI, and more. Gatekeeper is the component that wraps OPA into a K8s admission webhook.

Gatekeeper's two core concepts.

1. ConstraintTemplate — reusable Rego policy logic.
2. Constraint — an instance of that template (concrete parameters + scope).

ConstraintTemplate example — a pod must have certain labels.

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])
        }

And the matching 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 strengths.

• Declarative, non-procedural. Cross-resource conditions ("a Namespace must have a ServiceAccount and a RoleBinding") are easy.
• Set and array operations are extremely strong. Ideal for deep JSON structure validation.
• OPA itself runs outside K8s too. Validate Terraform plans in CI, make L7 authorization decisions in Envoy.

Weaknesses.

• The learning curve is genuinely steep. It takes weeks to feel fluent.
• The two-tier ConstraintTemplate / Constraint structure makes manifests verbose.
• Mutate is a separate component (Gatekeeper Mutation, beta). One tool does not finish the job.
• Viewing policy outcomes as native K8s resources is more awkward than Kyverno (mostly audit log).

In 2026 Gatekeeper continues to win in organizations with existing Rego investment and in shops that operate unified policy across Envoy and Terraform. New adoption has shifted toward Kyverno and VAP.

4. Validating Admission Policy (VAP) — k8s 1.30 GA (Apr 2024), built-in CEL

In April 2024 Kubernetes 1.30 made Validating Admission Policy (VAP) GA. This matters for several reasons.

• Built-in. No separate webhook component to install. kube-apiserver evaluates it directly.
• CEL (Common Expression Language) based. A lightweight expression language by Google, also used in gRPC, Envoy, IAM.
• Zero webhook call cost. Admission latency is much shorter than an external webhook.

The simplest example — reject a Deployment with fewer than five replicas.

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 must have at least 5 replicas"

Then a ValidatingAdmissionPolicyBinding defines where it applies.

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 has been growing in expressiveness. In 1.30 GA it was limited to simple comparisons; 1.31 and 1.32 added cross-resource lookups via paramRef and variables, authorizer checks, and namespace metadata references.

# A slightly richer example — container images must come from the corporate registry
validations:
  - expression: |
      object.spec.containers.all(c, c.image.startsWith('registry.corp.local/'))
    message: "Images must come from registry.corp.local/"

VAP strengths.

• Built-in, zero dependencies.
• Policies are K8s resources. GitOps-friendly.
• CEL evaluation is in-process — low latency.
• Native semantics for failurePolicy, auditAnnotations, warnings.

Weaknesses.

• Validate only. No mutate (that is MAP's territory — next section).
• More limited cross-resource lookup than Rego.
• CEL is still a new language. The barrier to entry is not as low as Kyverno's YAML.
• Policy library and ecosystem are thinner than Kyverno's as of 2026.

Recommended pattern: simple validate (label checks, field comparisons) goes in VAP, complex cross-resource + mutate goes in Kyverno. Running both in one cluster is becoming the 2026 standard.

5. Mutating Admission Policy (MAP) — k8s 1.32 alpha (Dec 2024)

In December 2024 Kubernetes 1.32 introduced Mutating Admission Policy (MAP) in alpha. The mutate sibling of VAP. Still alpha, so not production-ready, but likely to hit beta/GA inside 2026.

MAP supports two mutation styles.

1. ApplyConfiguration — build a typed server-side apply configuration object via CEL and merge.
2. JSON Patch — generate RFC 6902 JSON Patch via CEL.

ApplyConfiguration example — force a default securityContext on every Pod.

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"
                }
              }
            }
          }

If MAP reaches GA, parts of Kyverno's mutate domain will shift to built-in. That said, Kyverno's generate, policy report, and library remain differentiators.

2026 recommendation: treat MAP as experimental until 1.33+ beta stabilization, scope to simple default injection. Core mutate stays in Kyverno.

6. Pod Security Admission (PSA) — the built-in PSP replacement

Pod Security Policy (PSP) was deprecated in 1.21 and removed in 1.25. Pod Security Admission (PSA) took its place. Beta in 1.23, GA from 1.25, in 2026 effectively enabled by default everywhere.

PSA's three profiles.

PSA's three modes.

• enforce — block on violation.
• audit — write to audit log only.
• warn — surface a warning to kubectl.

Typical rollout: new namespaces start with warn=restricted, audit=restricted, enforce=baseline. After sufficient soak time, raise to 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

The fields PSA actually watches are narrow — hostPID, hostNetwork, privileged, runAsNonRoot, allowPrivilegeEscalation, seccompProfile, capabilities, and a handful more well-defined PSS fields. That means PSA guarantees the floor of pod security, and registry enforcement, label enforcement, custom policies sit on top via Kyverno/VAP.

The 2026 consensus: every prod namespace = PSA restricted enforce + Kyverno/VAP custom rules.

7. Rego vs CEL vs Cedar — comparing policy languages

Let us compare the policy languages themselves. Picking a tool is, in practice, picking a language.

One line of Rego.

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])
}

The same intent in CEL.

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

The same intent in Cedar (with a different policy-resource model, so not a 1:1 mapping).

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

What is interesting about Cedar is formal analysis — you can prove whether two policies contradict each other or which inputs the policy admits, using an SMT solver. AWS adopted Cedar as the new IAM language, and 2026 sees more Cedar-K8s integration PoCs, but it is not yet mainstream.

Practical recommendation.

• Existing Rego investment / Envoy + TF unification: keep OPA Gatekeeper.
• YAML only, please: Kyverno.
• Built-in + lightweight validate: VAP (CEL).
• AWS-heavy + policy formality matters: adopt Cedar partially outside K8s.

8. Falco — CNCF Graduated, the runtime security standard

Falco, created by Sysdig, is a runtime security engine that became CNCF Graduated in 2024. It watches everything admission could not — syscalls, file access, network IO inside containers.

How it works: hook kernel syscalls with kprobe (or an eBPF probe), stream them, and match against Falco rules.

# falco_rules.yaml — alert when a shell appears inside a container
- 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]

Priorities span NOTICE / WARNING / ERROR / CRITICAL. Outputs flow to stdout, syslog, gRPC, HTTP webhook, Slack, Loki, etc.

Representative Falco rules (from the default falco-rules set).

• "Write below etc" — a write happens under /etc/.
• "Read sensitive file untrusted" — sensitive files such as /etc/shadow are read.
• "Unexpected network outbound" — container connects to an unexpected external host.
• "Mining process detected" — known cryptominer patterns.

Operations.

• Falcosidekick: fans out Falco events to 50+ destinations (Slack, PagerDuty, Loki, S3, etc.).
• Falco Talon: turn alarms into automatic response (kill pod, apply NetworkPolicy).
• Drift detection: alert when a new binary appears in a container that was not in the image.

Weaknesses.

• Alarm only, no block (Falco itself). Unlike Tetragon or KubeArmor, it focuses on detect rather than enforce.
• Overhead on syscall-heavy workloads (partially mitigated by the eBPF driver).
• Without tuning, false positives dominate — in the first two weeks 90 percent of alarms can be noise.

The 2026 recommended stack: Falco (detect) + Tetragon/KubeArmor (enforce) + SIEM (Loki/Datadog) fan-out.

9. KubeArmor — CNCF Sandbox, eBPF + LSM-based enforce

KubeArmor, led by AccuKnox, is a runtime security tool at CNCF Sandbox stage. Its differentiator vs Falco is enforce, not just detect — by leveraging eBPF and Linux Security Modules (AppArmor, SELinux, BPF-LSM) it can outright block syscalls.

A KubeArmorPolicy example — block reads of /etc/shadow for a specific workload.

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

Three modes: action: Audit / Block / Allow. Block stops at the kernel and returns EPERM to the process.

KubeArmor strengths.

• Enforce capable. Unlike Falco, it actually blocks.
• LSM-based, harder to bypass.
• Per-pod policy. K8s selectors give workload-specific rules.
• Policy discovery: a mode that learns normal behavior and suggests policies automatically.

Weaknesses.

• Sandbox, so ecosystem and maturity trail Falco.
• Needs a kernel with LSM (and especially BPF-LSM) enabled (5.7+).
• A wrong policy can kill legitimate workloads — verify in Audit mode first, then Block.

Recommended pattern: Falco for alarms, KubeArmor for enforce. They are complementary, not competitors.

10. Cilium Tetragon — eBPF observability + security

Tetragon, by Isovalent (Cilium's company, acquired by Cisco in 2023), is an eBPF-based runtime security and observability tool. Sister project of Cilium, sharing the same eBPF infrastructure.

Tetragon differentiators.

• Depth of kernel hooks. Polymorphic hooks over tracepoint, kprobe, uprobe.
• Process lineage. Tracks parent-child relationships for every process — "which web request started this cryptominer?" becomes answerable.
• Enforce capable. Block syscalls via SIGKILL signal injection or override return.
• Observability as a first-class citizen. Events stream as JSON — native integrations with Grafana, ELK, Datadog.

A TracingPolicy example — watch opens of /etc/passwd inside containers.

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

This policy kills any process the moment it opens /etc/passwd. It combines Falco's detect with KubeArmor's enforce in a single tool.

In 2026.

• Naturally adopted alongside Cilium. If your CNI is Cilium, Tetragon adoption is nearly free.
• Advanced forensics. The traceable process tree beats Falco for post-incident investigation.
• Often run with Falco. Falco has a richer rule library; Tetragon has deeper hooks.

Weaknesses.

• Learning curve steeper than Falco.
• Without Cilium in the stack, adoption motivation is weak.

11. Sigstore Policy Controller + Connaisseur — enforcing signed images

The crux of supply chain security: what enters the cluster. The 2026 standard is twofold — cosign signing from Sigstore (Linux Foundation) and an admission controller enforcing those signatures in K8s.

The Sigstore ecosystem.

• cosign — CLI to sign and verify container images.
• fulcio — issues short-lived signing certificates (backed by a CT log).
• rekor — transparency log recording every signature (immutable).
• Sigstore Policy Controller — verifies cosign signatures at K8s admission.

The simplest flow.

# On the build machine (CI)
cosign sign --yes ghcr.io/corp/api:v1.2.3

# Or keyless (OIDC-driven)
COSIGN_EXPERIMENTAL=1 cosign sign --yes \
  --identity-token=$(cat /var/run/secrets/tokens/oidc) \
  ghcr.io/corp/api:v1.2.3

Verification policy (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/.*"

In a namespace where this policy applies, only images signed via the GitHub Actions OIDC token are admitted. Even without managing keys (keyless), this works — the fulcio + rekor magic.

Connaisseur (open source from SAP) is another option. It supports multiple backends — signed images via Notary v1/v2, cosign, and Docker Content Trust. If Sigstore Policy Controller is cosign-only, Connaisseur covers many.

# Excerpt of 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 recommendation: OIDC keyless cosign + Sigstore Policy Controller is simplest. Multi-backend or regulated environments lean toward Connaisseur.

12. Trivy Operator — native K8s integration of image scanning

Aqua Security's Trivy is the most widely used OSS CVE scanner. Trivy Operator wraps it as a K8s-native controller — it scans images and resources across the cluster on a schedule and records results as K8s resources (VulnerabilityReport, ConfigAuditReport, ExposedSecretReport).

# Auto-generated VulnerabilityReport example after Trivy Operator is installed
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
      ...

These resources can flow to Grafana / Loki / Datadog, or feed back into a Kyverno admission policy like "reject images with any Critical CVE."

Scan targets.

• Container images — base OS packages plus language packages (npm, pip, go.mod, etc.).
• K8s resource misconfig — Trivy's K8s rule set.
• Secrets — secrets leaked in images or manifests.
• SBOM generation — CycloneDX, SPDX.

2026 recommendation: scan in CI at build time, run Trivy Operator for continuous in-cluster scans, and use Kyverno to reject Critical CVEs — three layers of defense.

13. Polaris / Goldilocks (Fairwinds) — resource right-sizing

Two Fairwinds open source tools. Less "security" than "best practice automation."

Polaris checks manifests against best practices: missing CPU/memory limits, missing runAsNonRoot, use of the latest tag, and 100+ other rules. Three modes — admission webhook, CI, dashboard.

# Polaris config excerpt
checks:
  cpuLimitsMissing: warning
  memoryLimitsMissing: warning
  runAsRootAllowed: danger
  hostIPCSet: danger
  notReadOnlyRootFilesystem: warning

Goldilocks uses the VerticalPodAutoscaler recommendation mode to compute suggested request/limit per workload and surface them in a dashboard. Things like "this deployment's CPU request can drop to 50m."

# Install Goldilocks (helm)
helm install goldilocks fairwinds-stable/goldilocks --namespace goldilocks
# Label namespaces you want monitored
kubectl label ns prod goldilocks.fairwinds.com/enabled=true

Neither is strictly security, but given that misconfiguration drives over 60 percent of security incidents, they belong in the security stack.

14. Kubescape (ARMO) — security posture evaluation

Kubescape, originally by ARMO (now CNCF Incubating, promoted in 2023), evaluates clusters against frameworks like NSA-CISA Kubernetes Hardening Guidance, MITRE ATT&CK, and the CIS Kubernetes Benchmark.

# Scan the cluster against the NSA framework
kubescape scan framework nsa

# Example output
# Control: C-0007 Data Destruction
# Resources: 23
# Compliance Score: 87.5%
# Failed: 3 resources
# ...

Features.

• Many frameworks — NSA, MITRE, CIS, ArmoBest, AllControls.
• IDE integration — VS Code extension evaluates manifests as you write.
• GitOps-friendly — drop kubescape scan into CI to block at PR.
• Both a hosted SaaS (ARMO Platform) and an OSS CLI exist.

What Kubescape does differently: end-to-end evaluation. Not just admission, not just runtime — RBAC, network policy, images, configuration are all evaluated together.

# Scan a single workload
kubescape scan workload deployment/api -n prod

# Scan YAML files directly (for CI)
kubescape scan ./manifests/*.yaml

15. kube-bench / kube-hunter / kube-score / Checkov K8s — the supporting cast

Finally, four helpers frequently used together.

kube-bench (Aqua Security) — runs the CIS Kubernetes Benchmark. Roughly 200 checks across control plane node, etcd, kubelet, policies.

# Run kube-bench as a Job on a node
kubectl apply -f https://raw.githubusercontent.com/aquasecurity/kube-bench/main/job.yaml
kubectl logs -l job-name=kube-bench

# Sample output
# [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-specific variants exist (eks-bench, etc.).

kube-hunter (Aqua) — actively hunts the cluster from outside (or inside). A pen-testing tool. Surfaces things like "etcd exposed without authentication."

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

kube-score — a simple static analyzer for manifests. Assigns scores.

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

Easy to drop into CI.

Checkov (Bridgecrew, now Palo Alto) — broad IaC static analysis. Terraform, CloudFormation, K8s, Helm, Kustomize, Dockerfile, and more. 800+ policies cover K8s manifests too.

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

Recommended use.

• kube-bench: once at cluster setup, then quarterly.
• kube-hunter: when onboarding a new cluster, red-team style.
• kube-score: at the manifest PR stage in CI.
• Checkov: as the unified IaC gate (TF + K8s + Docker).

16. Korean and Japanese K8s security — Toss, Kakao, Mercari

Finally, how the Korean and Japanese big tech companies run K8s security. (Based on public conference talks and engineering blogs.)

Toss

Toss is a payments company, so PCI-DSS shapes everything. The K8s security stack.

• PSA restricted enforce is the default for every prod namespace.
• Many Kyverno policies — registry enforcement, label/owner enforcement, automatic NetworkPolicy generation.
• In-house admission webhooks — domain-specific rules Kyverno cannot model (e.g., validating a specific Helm chart for the payment service) live in custom webhooks.
• Falco + Loki + Grafana — the runtime alert stack.
• Image signing — internal CI signs with cosign; Sigstore Policy Controller enforces.
• Trivy Operator — daily CVE scans, results piped to the internal security dashboard.

Toss conferences such as SLASH increasingly feature "migrating to Kyverno" and "rolling out PSA" sessions.

Kakao

Kakao spans many subsidiaries, with K8s spread across an in-house platform (DKOS and Kubeflow-derived stacks) by Kakao Enterprise. From public if(kakao) talks.

• OPA Gatekeeper is still common — Rego assets exist internally, and there is unification across Envoy and IaC.
• Kyverno adoption is rising for new services.
• Falco and kube-bench are baseline.
• Parts of Kakao Enterprise's SaaS portfolio use Kubescape for periodic audits.

Mercari

Mercari is GCP-centric but very progressive on the K8s security stack.

• Early adopters of Sigstore + cosign + Sigstore Policy Controller. Mercari Engineering blog has detailed writeups on keyless signing rollout.
• Kyverno is the standard admission tool, paired with GKE PSA.
• Falco plus GKE Container Threat Detection run together.
• Trivy is used on both build and runtime.

LINE and Yahoo Japan

LINE, given global traffic, has a homegrown security platform. The K8s piece mixes OPA and Kyverno, with Falco on runtime. Yahoo Japan looks similar.

Common patterns

All three companies share.

• PSA as the floor, with Kyverno (or OPA) on top for custom rules.
• Falco dominates runtime, with Tetragon showing up wherever Cilium is the CNI.
• Image signing converges on cosign.
• Trivy is the CVE standard.

The 2026 trend across Korea and Japan: not a single tool for everything but a per-layer stack of right-sized tools is becoming standard.

17. Who should pick what — by scenario

A one-page decision sheet.

Operationally, do not forget.

• Dry-run first. New policies start in audit/warn mode for one to two weeks before enforce.
• Policies are code. Manage via GitOps (Argo/Flux), require PR review.
• Watch alert fatigue. Turning on Falco rules cold means 90 percent noise. Tune for a week before enforce.
• Drift detection. The moment cluster policy diverges from Git, your security model collapses.
• Image signing covers 80 percent of supply chain. Read it together with the SLSA framework.

Epilogue — security is an ensemble of layers, not a tool

The honest lesson of K8s security in 2026 is not about tools but about the ensemble. Admission blocks, runtime watches, images verify, posture audits periodically. Turn off any one layer and the surface area opens up.

Tools change. Five years ago the operator of PSP runs PSA + Kyverno + VAP today and may operate MAP next year. But the team that understands the layers survives a tool change. The team that leans on a single tool collapses the moment that tool is deprecated (witness Datree's sunset in 2023).

Candidate follow-ups: Cosign and SLSA — the real depth of supply chain security, 100 Kyverno policies you can lift verbatim into production, Tetragon process tree forensics — tracing cryptominer back through the call chain.

"Security is not admission alone. If only admission is on, everything past admit is unguarded."

— K8s admission policies and security, 2026. The end.

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