Kubernetes Security Posture Management in 2026: From Pod Security to Supply Chain, Runtime Defense, and Zero Trust

Updated (March 2026): Complete rewrite replacing the original 2023 overview with the current KSPM landscape. Covers Pod Security Standards (PSS), supply chain security with SBOM and Sigstore, eBPF runtime monitoring (Falco, Tetragon, KubeArmor), Cilium network policies, secret management with External Secrets Operator, RBAC hardening, CIS Benchmarks, KSPM platforms (Aqua, Prisma Cloud, Sysdig, Wiz, ARMO), policy-as-code (OPA Gatekeeper, Kyverno, Kubewarden), container image scanning, multi-cluster governance, incident response playbooks, and real breach case studies from 2023 through 2025.

The Security Landscape Has Changed

When this article was first published, Kubernetes Security Posture Management meant scanning for misconfigurations and hoping your RBAC rules were not too permissive. Three years later, KSPM has become a multi-layered discipline that touches every stage of the container lifecycle — from code commit to runtime syscall.

The numbers tell the story. According to the CNCF Annual Survey 2025, 96% of organizations are either using or evaluating Kubernetes. The Red Hat State of Kubernetes Security Report 2025 found that 67% of organizations delayed or slowed application deployment because of security concerns. More critically, 45% experienced a security incident in their Kubernetes environments within the preceding 12 months.

KSPM in 2026 is no longer optional tooling bolted onto a cluster. It is a foundational architecture decision that determines whether your workloads survive contact with real adversaries.

What Changed from 2023 to 2026

The shift was not gradual — it was structural. Several foundational changes reshaped how teams approach Kubernetes security:

Pod Security Policies died. Removed entirely in Kubernetes v1.25 (August 2022), PodSecurityPolicy (PSP) was replaced by Pod Security Standards (PSS) enforced through the built-in Pod Security Admission controller. Teams that delayed migration found themselves on unsupported Kubernetes versions with no path forward.

Supply chain attacks became the primary threat vector. The SolarWinds aftermath, the Codecov breach, the ua-parser-js npm compromise, and the XZ Utils backdoor (March 2024) proved that attackers target the build pipeline, not just the runtime. SBOM generation, image signing with Sigstore, and admission controllers that verify signatures became table stakes.

eBPF replaced kernel modules for runtime security. Falco moved to eBPF by default. Cilium Tetragon reached GA. KubeArmor matured. Runtime security shifted from log parsing to kernel-level observability with negligible performance overhead.

Policy-as-code became enforceable, not advisory. OPA Gatekeeper and Kyverno moved beyond audit mode into hard enforcement in production, backed by extensive policy libraries covering CIS Benchmarks, NSA/CISA hardening guides, and NIST SP 800-190.

Zero trust networking arrived in Kubernetes. Cilium replaced kube-proxy in multiple distributions. Istio ambient mesh eliminated sidecars. Network policies moved from "nice to have" to "mandatory in every namespace."

Pod Security Standards: The PSP Replacement

Pod Security Policies were deprecated in Kubernetes v1.21 (April 2021) and removed in v1.25 (August 2022). Their replacement — Pod Security Standards (PSS) — defines three profiles enforced by the built-in Pod Security Admission (PSA) controller.

The Three Profiles

Privileged: No restrictions. Used only for system-level workloads like CNI plugins, storage drivers, and log collectors that require host access. In a well-architected cluster, fewer than 5% of pods should run at this level.

Baseline: Prevents known privilege escalations. Blocks hostNetwork, hostPID, hostIPC, privileged containers, and most dangerous volume types. This is the minimum acceptable standard for application workloads in 2026.

Restricted: Maximum security. Requires non-root execution, drops ALL capabilities, enforces read-only root filesystems, and mandates seccomp profiles. This profile aligns with CIS Benchmark recommendations and should be the default for all application namespaces.

Enforcement Modes

PSA operates in three modes per namespace, configured via labels:

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

• enforce rejects pods that violate the policy
• audit logs violations to the API server audit log but allows the pod
• warn sends warnings to the kubectl user but allows the pod

The recommended migration path: start with warn across all namespaces, review warnings for 30 days, move to audit for another 30 days while fixing violations, then switch to enforce. Teams that skip directly to enforce invariably break production workloads.

Beyond PSA: Where It Falls Short

PSA is intentionally simple. It does not support field-level exceptions, custom policies, mutation, or external data lookups. For those capabilities, you need a policy engine — OPA Gatekeeper or Kyverno. In practice, most mature organizations use PSA as a baseline safety net and layer a policy engine on top for granular control.

Supply Chain Security

Supply chain security moved from conference talk to production requirement after a cascade of high-profile incidents between 2020 and 2024. Kubernetes environments are particularly vulnerable because they pull container images from registries, consume Helm charts from repositories, and run admission webhooks from third-party sources — each a potential vector.

Software Bill of Materials (SBOM)

An SBOM is a machine-readable inventory of every component in a software artifact. For container images, this means every OS package, language-specific dependency, and statically linked binary.

The US Executive Order 14028 (May 2021) mandated SBOMs for software sold to the federal government. By 2025, the EU Cyber Resilience Act extended similar requirements to all software sold in the European market. SBOM generation is no longer optional for any organization with government customers or European exposure.

Tooling in 2026:

• Syft (Anchore): generates SBOMs in SPDX and CycloneDX formats from container images, filesystems, and archives
• Trivy (Aqua): generates SBOMs alongside vulnerability scanning in a single pass
• docker sbom: built into Docker Desktop and Docker Scout, uses Syft under the hood
• Kubernetes BOM (bom): CNCF tool specifically designed for Kubernetes release artifacts

The standard practice is to generate SBOMs during the CI pipeline, attach them to the container image as a cosign attachment, and verify their presence via admission controller before allowing deployment.

Sigstore: Keyless Image Signing

Sigstore — comprising Cosign, Fulcio, and Rekor — has become the de facto standard for container image signing. It eliminates the key management problem that made traditional GPG signing impractical at scale.

How it works:

1. Developer authenticates via OIDC (GitHub Actions, Google, Microsoft)
2. Fulcio issues a short-lived signing certificate tied to the OIDC identity
3. Cosign signs the container image digest with this certificate
4. The signature and certificate are recorded in Rekor, an immutable transparency log
5. Verification checks the Rekor log — no keys to distribute or rotate

By 2026, every major CI platform supports Sigstore natively. GitHub Actions generates Sigstore attestations automatically for container builds. GitLab CI, CircleCI, and Buildkite have equivalent integrations.

# Sign an image (keyless)
cosign sign ghcr.io/myorg/myapp:v1.2.3

# Verify an image
cosign verify \
  --certificate-identity=https://github.com/myorg/myapp/.github/workflows/build.yml@refs/heads/main \
  --certificate-oidc-issuer=https://token.actions.githubusercontent.com \
  ghcr.io/myorg/myapp:v1.2.3

Admission Controllers for Supply Chain Verification

Signing images means nothing if you do not enforce verification at deployment time. Three admission controllers dominate this space:

Kyverno handles image verification natively with its verifyImages rule type. It can validate Cosign signatures, check Sigstore attestations, verify SBOM presence, and enforce SLSA provenance levels — all in a single policy.

Sigstore Policy Controller (formerly known as cosigned) is purpose-built for Sigstore verification. It runs as a Kubernetes admission webhook and rejects any pod whose images lack valid Sigstore signatures or attestations matching configured trust roots.

Connaisseur is a more focused alternative that validates image signatures against configured trust roots before allowing deployment, supporting Cosign, Notary v2, and custom signature formats.

In production, the recommended architecture is to use Kyverno or OPA Gatekeeper as the primary policy engine with image verification as one of many enforced policies, rather than running a standalone signature verification webhook.

SLSA Framework

Supply-chain Levels for Software Artifacts (SLSA, pronounced "salsa") provides a graduated security framework for supply chain integrity:

• SLSA Level 1: Documentation of the build process, automated build
• SLSA Level 2: Version-controlled source, hosted build service, authenticated provenance
• SLSA Level 3: Hardened build platform, unforgeable provenance
• SLSA Level 4: Two-person review, hermetic reproducible builds

GitHub Actions achieved SLSA Level 3 build provenance in 2023 via the SLSA GitHub Generator. By 2026, most CI platforms support at least Level 2, and federal procurement increasingly requires Level 3.

Runtime Security: The eBPF Revolution

Traditional runtime security relied on kernel modules (like the original Falco implementation), log file parsing, or ptrace-based monitoring. Each approach carried significant overhead, stability risks, or visibility gaps. eBPF changed everything.

eBPF (extended Berkeley Packet Filter) allows programs to run in the Linux kernel without modifying kernel source code or loading kernel modules. For security, this means observing every syscall, network connection, file access, and process execution with negligible performance impact — typically under 2% CPU overhead.

Falco

Falco — created by Sysdig and donated to CNCF (graduated December 2024) — is the most widely deployed Kubernetes runtime security tool. The project transitioned from a kernel module driver to eBPF as the default in Falco 0.35 (2023), and modern Falco (v0.39+) runs exclusively with its modern eBPF probe on supported kernels.

Falco works by monitoring Linux kernel syscalls and generating alerts when observed behavior matches predefined rules. It ships with a comprehensive default ruleset covering:

• Container escapes (namespace changes, mount manipulation)
• Cryptomining detection (known miner binaries, suspicious CPU patterns)
• Reverse shells and unexpected network connections
• Sensitive file reads (/etc/shadow, /etc/kubernetes/pki)
• Package management in running containers
• Privilege escalation attempts

# Example Falco rule: detect shell in container
- rule: Terminal shell in container
  desc: Detect a shell being opened inside a container
  condition: >
    spawned_process and container and shell_procs and proc.tty != 0
  output: >
    Shell opened in container (user=%user.name container=%container.name
    image=%container.image.repository shell=%proc.name parent=%proc.pname)
  priority: WARNING
  tags: [container, shell, mitre_execution]

Falco's ecosystem in 2026 includes Falcosidekick (40+ output integrations including Slack, PagerDuty, AWS SecurityHub, and Elasticsearch), Falco Talon for automated response actions, and the Falco Plugins framework for extending detection beyond syscalls to CloudTrail, Okta, and GitHub audit logs.

Cilium Tetragon

Tetragon — created by Isovalent (acquired by Cisco in December 2023) and now part of the Cilium project under CNCF — takes a different approach from Falco. While Falco observes and alerts, Tetragon can enforce at the kernel level. Its TracingPolicy CRD allows security teams to define eBPF-based policies that can block operations in real time, not just detect them after the fact.

apiVersion: cilium.io/v1alpha1
kind: TracingPolicy
metadata:
  name: block-sensitive-file-writes
spec:
  kprobes:
    - call: security_file_open
      syscall: false
      args:
        - index: 0
          type: file
      selectors:
        - matchArgs:
            - index: 0
              operator: Prefix
              values:
                - /etc/kubernetes/pki
                - /etc/shadow
          matchActions:
            - action: Sigkill

Tetragon excels at process lifecycle tracking, providing full process trees that show exactly how an attacker moved from initial access to their objective. This is invaluable for incident response — instead of correlating logs across multiple sources, Tetragon shows the complete execution chain.

KubeArmor

KubeArmor — a CNCF sandbox project — provides a higher-level abstraction over eBPF and Linux Security Modules (LSM). While Falco and Tetragon require writing low-level syscall rules, KubeArmor allows security teams to express policies in terms of Kubernetes primitives:

apiVersion: security.kubearmor.com/v1
kind: KubeArmorPolicy
metadata:
  name: block-package-managers
  namespace: production
spec:
  selector:
    matchLabels:
      app: web-frontend
  process:
    matchPaths:
      - path: /usr/bin/apt
      - path: /usr/bin/apt-get
      - path: /usr/bin/yum
      - path: /usr/bin/dnf
    action: Block
  file:
    matchDirectories:
      - dir: /etc/
        readOnly: true
    action: Block

KubeArmor is particularly useful for organizations that want runtime enforcement without deep kernel expertise. It auto-discovers workload behavior to generate baseline policies, reducing the risk of false positives when first deployed.

Network Policies and Service Mesh Security

Network segmentation inside Kubernetes has evolved from a best practice to a compliance requirement. In a default Kubernetes installation, every pod can communicate with every other pod — a flat network that gives attackers free lateral movement after initial compromise.

Kubernetes Network Policies

Native Kubernetes NetworkPolicy resources provide basic ingress and egress controls at layers 3 and 4 (IP/port):

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

This default-deny policy should be applied to every namespace as a baseline. Every workload then gets an explicit allow policy for its required communication paths. The challenge is that native NetworkPolicy lacks DNS-based rules, layer 7 filtering, and cluster-wide scope. For those capabilities, you need Cilium.

Cilium Network Policies

Cilium — the default CNI in Google Kubernetes Engine (GKE), Amazon EKS (since EKS v1.28), and Azure AKS — replaced kube-proxy with eBPF dataplane in all three major cloud providers by 2025. Its CiliumNetworkPolicy CRD extends native NetworkPolicy with:

• Layer 7 filtering: HTTP method/path, gRPC service/method, Kafka topic, DNS name
• FQDN-based egress: allow traffic to api.stripe.com without hardcoding IP addresses
• Cluster-wide policies: CiliumClusterwideNetworkPolicy applies across all namespaces
• Identity-based policies: policies based on Kubernetes labels and service accounts, not just IP addresses

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: api-gateway-policy
  namespace: production
spec:
  endpointSelector:
    matchLabels:
      app: api-gateway
  egress:
    - toEndpoints:
        - matchLabels:
            app: backend-service
      toPorts:
        - ports:
            - port: '8080'
              protocol: TCP
          rules:
            http:
              - method: GET
                path: /api/v1/.*
              - method: POST
                path: /api/v1/orders
    - toFQDNs:
        - matchName: api.stripe.com
      toPorts:
        - ports:
            - port: '443'
              protocol: TCP

Istio and Service Mesh Security

Istio ambient mesh — which reached GA in Istio 1.22 (May 2025) — eliminated the sidecar proxy requirement that made service mesh adoption prohibitively expensive for large clusters. Ambient mesh uses a shared ztunnel (zero-trust tunnel) DaemonSet for layer 4 mTLS and optional waypoint proxies for layer 7 policies, reducing memory overhead by 90% compared to sidecar-per-pod.

Istio's AuthorizationPolicy provides application-layer access control:

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: payment-service-policy
  namespace: production
spec:
  selector:
    matchLabels:
      app: payment-service
  rules:
    - from:
        - source:
            principals:
              - cluster.local/ns/production/sa/api-gateway
      to:
        - operation:
            methods: ['POST']
            paths: ['/api/v1/payments/*']
      when:
        - key: request.headers[x-request-id]
          notValues: ['']

The combination of Cilium for network-level enforcement and Istio for application-level authorization provides defense in depth: even if an attacker compromises a pod, they cannot reach services outside their explicit allow list, and they cannot invoke unauthorized API operations on services they can reach.

Secret Management Evolution

Kubernetes Secrets are base64-encoded, not encrypted. Anyone with RBAC permission to read Secrets in a namespace can decode them trivially. This has been a known limitation since Kubernetes 1.0, and the ecosystem has built increasingly sophisticated solutions on top.

External Secrets Operator

External Secrets Operator (ESO) — the clear winner in the Kubernetes secrets management space by 2026 — syncs secrets from external providers (AWS Secrets Manager, Azure Key Vault, Google Secret Manager, HashiCorp Vault, 1Password, CyberArk, and dozens more) into Kubernetes Secrets. The external provider remains the source of truth, and ESO handles rotation, formatting, and lifecycle.

apiVersion: external-secrets.io/v1
kind: ExternalSecret
metadata:
  name: database-credentials
  namespace: production
spec:
  refreshInterval: 5m
  secretStoreRef:
    name: aws-secrets-manager
    kind: ClusterSecretStore
  target:
    name: db-credentials
    creationPolicy: Owner
    deletionPolicy: Retain
  data:
    - secretKey: username
      remoteRef:
        key: production/database
        property: username
    - secretKey: password
      remoteRef:
        key: production/database
        property: password

HashiCorp Vault Integration

IBM acquired HashiCorp for $6.4 billion in April 2024, and Vault transitioned to the Business Source License (BSL). Despite license concerns, Vault remains the most feature-complete secrets management platform for Kubernetes. The Vault Secrets Operator (VSO) — which replaced the older Vault Agent Injector and CSI Provider — provides a Kubernetes-native interface:

apiVersion: secrets.hashicorp.com/v1beta1
kind: VaultStaticSecret
metadata:
  name: vault-db-creds
  namespace: production
spec:
  vaultAuthRef: default
  mount: secret
  path: production/database
  type: kv-v2
  refreshAfter: 60s
  destination:
    name: db-credentials
    create: true

OpenBao — the Linux Foundation fork of Vault created in response to the BSL change — reached v2.1 by early 2026 and is gaining traction among organizations uncomfortable with IBM/HashiCorp licensing.

Encryption at Rest

Kubernetes supports encryption at rest for Secrets stored in etcd. In 2026, the recommended configuration uses KMS v2 (stable since Kubernetes v1.29) with a cloud provider's key management service:

apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
  - resources:
      - secrets
    providers:
      - kms:
          apiVersion: v2
          name: aws-kms-provider
          endpoint: unix:///var/run/kmsplugin/socket.sock
      - identity: {}

The defense-in-depth approach for secrets in 2026: encrypt at rest with KMS v2, use External Secrets Operator or Vault Secrets Operator to sync from external providers, enforce RBAC restrictions on Secret access, enable audit logging for all Secret reads, and rotate credentials automatically on a schedule.

RBAC Best Practices and Audit Logging

Role-Based Access Control remains the primary authorization mechanism in Kubernetes, and misconfigured RBAC is consistently among the top findings in cluster security assessments.

RBAC Anti-Patterns

The most dangerous RBAC misconfigurations in production clusters:

Wildcard permissions: Granting verbs: ["*"] on resources: ["*"] in apiGroups: ["*"] creates a cluster-admin equivalent. This pattern appears in approximately 28% of scanned clusters according to Wiz's 2025 Kubernetes Security Report.

Unnecessary cluster-admin bindings: The cluster-admin ClusterRole should be bound to fewer than 5 principals in any cluster. Many organizations bind it to CI/CD service accounts, developer groups, or monitoring tools that do not require full cluster access.

Privilege escalation via RBAC: Users with permission to create or modify Roles/RoleBindings can escalate their own privileges. Kubernetes v1.28+ includes safeguards (the escalate verb), but many organizations run older versions or have not audited existing bindings.

Secret access sprawl: Any service account with get or list permissions on Secrets in a namespace can read all secrets in that namespace, including those belonging to other workloads. Use separate namespaces for workloads with different trust levels.

Audit Logging

Kubernetes API server audit logging captures every request to the API server with configurable verbosity:

apiVersion: audit.k8s.io/v1
kind: Policy
rules:
  # Log Secret access at RequestResponse level
  - level: RequestResponse
    resources:
      - group: ''
        resources: ['secrets']
    omitStages:
      - RequestReceived

  # Log RBAC changes
  - level: RequestResponse
    resources:
      - group: rbac.authorization.k8s.io
        resources:
          ['clusterroles', 'clusterrolebindings', 'roles', 'rolebindings']

  # Log pod exec (common attacker technique)
  - level: RequestResponse
    resources:
      - group: ''
        resources: ['pods/exec', 'pods/attach']

  # Log everything else at Metadata level
  - level: Metadata
    omitStages:
      - RequestReceived

In managed Kubernetes services, audit logs should flow to a centralized SIEM: CloudWatch Logs for EKS, Cloud Logging for GKE, Azure Monitor for AKS. The critical alerts to configure: any cluster-admin binding creation, any Secret access outside normal service account patterns, any pod exec into production namespaces, and any RBAC modification.

CIS Kubernetes Benchmarks and Automated Compliance

The Center for Internet Security (CIS) Kubernetes Benchmark — currently at v1.9 (released March 2025) — provides a comprehensive checklist of security recommendations for Kubernetes clusters. The benchmark covers API server configuration, etcd security, controller manager settings, scheduler configuration, node security, and workload policies.

Key CIS Recommendations for 2026

The most impactful CIS controls that organizations frequently fail:

1. Enable audit logging (CIS 3.2.1): Only 62% of clusters have audit logging enabled according to the 2025 CNCF Security Audit
2. Ensure RBAC is enabled (CIS 1.2.7): Universally enabled in managed K8s but often bypassed via overly permissive bindings
3. Encrypt etcd data at rest (CIS 1.2.29): Only 48% of self-managed clusters encrypt etcd
4. Restrict kubelet anonymous auth (CIS 4.2.1): Still exposed in 12% of scanned clusters
5. Apply Pod Security Standards (CIS 5.1): Only 35% of namespaces enforce the restricted profile

Automated Benchmarking Tools

kube-bench (Aqua Security) is the standard tool for running CIS Benchmark checks. It runs as a Job or DaemonSet and produces reports detailing pass, fail, and warning status for each control:

# Run CIS benchmark against a cluster
kubectl apply -f https://raw.githubusercontent.com/aquasecurity/kube-bench/main/job.yaml
kubectl logs job/kube-bench

Kubescape (ARMO) goes beyond CIS to include NSA/CISA Kubernetes Hardening Guide, MITRE ATT&CK for Containers, and custom framework support. It provides a risk score and prioritized remediation guidance.

Compliance Operator (Red Hat/OpenShift) enforces compliance profiles continuously, automatically remediating drift. It supports CIS, NIST 800-53, PCI-DSS, and HIPAA profiles.

KSPM Platforms in 2026

The KSPM vendor landscape has consolidated significantly since 2023. Cloud Security Posture Management (CSPM) vendors expanded into Kubernetes, Kubernetes-native security vendors expanded into cloud, and the result is a set of comprehensive Cloud-Native Application Protection Platforms (CNAPP) that cover the full stack.

Aqua Security

Aqua pioneered container security and remains one of the strongest Kubernetes-focused vendors. Key differentiators in 2026: Trivy (their open-source scanner) is the most widely used vulnerability scanner in the CNCF ecosystem, Aqua Enforcer provides runtime protection using eBPF, and their supply chain security module handles SBOM, image signing, and SLSA attestation verification. Aqua's open-source contributions (Trivy, kube-bench, Tracee, kube-hunter) give them deep credibility in the Kubernetes community.

Palo Alto Networks Prisma Cloud

Prisma Cloud provides the broadest coverage across cloud providers and Kubernetes distributions. Its Defender DaemonSet monitors runtime behavior, and its Admission Controller enforces policies at deployment time. Prisma Cloud's strength is correlation across layers — connecting a misconfigured IAM role in AWS to an over-privileged pod in EKS to a running exploit chain. The acquisition of Twistlock (2019) and Bridgecrew (2021) consolidated container security and infrastructure-as-code scanning into a single platform.

Sysdig

Sysdig created Falco and continues to build its commercial platform on the same kernel-level visibility. Sysdig Secure provides runtime threat detection using Falco rules, image scanning with vulnerability prioritization based on runtime usage (only alerting on vulnerabilities in packages that are actually loaded into memory), and compliance monitoring against CIS, NIST, PCI, [SOC 2](https://glossary.crashbytes.com/soc), and HIPAA. Their "runtime intelligence" approach — focusing remediation on vulnerabilities that are actually exploitable in the running environment — significantly reduces alert fatigue.

Wiz

Wiz — the fastest-growing cybersecurity company in history, reaching $350 million ARR in under three years — takes an agentless approach to Kubernetes security. Rather than deploying DaemonSets into clusters, Wiz scans cloud provider APIs, container registries, and Kubernetes API servers from outside the cluster. This approach provides broad visibility with zero runtime overhead but lacks the deep syscall-level monitoring of agent-based tools like Falco or Sysdig. Wiz excels at identifying attack paths that cross cloud and Kubernetes boundaries — for example, an internet-facing load balancer routing to a pod with a critical CVE running with a service account that has access to an S3 bucket containing PII.

ARMO (Kubescape)

ARMO, the company behind Kubescape, provides an open-source-first KSPM platform. Kubescape is the first Kubernetes security tool to become a CNCF project (sandbox, 2023). ARMO Platform adds runtime threat detection, image scanning, network policy generation, and continuous compliance monitoring on top of the open-source scanner. Their approach of automatically generating security configurations (network policies, seccomp profiles, RBAC rules) based on observed workload behavior is particularly useful for brownfield deployments.

Policy-as-Code: Enforcing Standards at Admission

Policy-as-code is the practice of expressing security, compliance, and operational policies as machine-readable code that is version-controlled, tested, and enforced automatically. In Kubernetes, this means admission controllers that evaluate every API request against a policy library and either allow, deny, or mutate the request.

OPA Gatekeeper

Open Policy Agent (OPA) Gatekeeper — a CNCF graduated project — uses the Rego policy language to define constraints. Gatekeeper introduces two CRDs: ConstraintTemplates (parameterized policy definitions) and Constraints (instances of those templates applied to specific resources).

# ConstraintTemplate: require resource limits
apiVersion: templates.gatekeeper.sh/v1
kind: ConstraintTemplate
metadata:
  name: k8srequiredlimits
spec:
  crd:
    spec:
      names:
        kind: K8sRequiredLimits
  targets:
    - target: admission.k8s.gatekeeper.sh
      rego: |
        package k8srequiredlimits
        violation[{"msg": msg}] {
          container := input.review.object.spec.containers[_]
          not container.resources.limits.cpu
          msg := sprintf("Container %v has no CPU limit", [container.name])
        }
        violation[{"msg": msg}] {
          container := input.review.object.spec.containers[_]
          not container.resources.limits.memory
          msg := sprintf("Container %v has no memory limit", [container.name])
        }
---
# Constraint: apply to all pods in production
apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sRequiredLimits
metadata:
  name: require-limits-production
spec:
  match:
    kinds:
      - apiGroups: ['']
        kinds: ['Pod']
    namespaces: ['production']

Gatekeeper's strength is its flexibility — Rego can express almost any policy logic, including policies that reference external data. Its weakness is Rego's learning curve; it is a purpose-built query language that most Kubernetes engineers find unintuitive.

Kyverno

Kyverno — a CNCF incubating project — took a different approach by expressing policies in YAML, the language Kubernetes engineers already know. By 2026, Kyverno has surpassed Gatekeeper in new deployments, particularly among organizations without dedicated policy engineering teams.

Kyverno supports validation (reject non-compliant resources), mutation (modify resources to add defaults), generation (create resources automatically), and image verification (validate container image signatures):

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-signed-images
spec:
  validationFailureAction: Enforce
  background: false
  rules:
    - name: verify-signature
      match:
        any:
          - resources:
              kinds:
                - Pod
      verifyImages:
        - imageReferences:
            - 'ghcr.io/myorg/*'
          attestors:
            - entries:
                - keyless:
                    subject: 'https://github.com/myorg/*'
                    issuer: 'https://token.actions.githubusercontent.com'
                    rekor:
                      url: https://rekor.sigstore.dev
    - name: add-security-context
      match:
        any:
          - resources:
              kinds:
                - Pod
      mutate:
        patchStrategicMerge:
          spec:
            containers:
              - (name): '*'
                securityContext:
                  runAsNonRoot: true
                  allowPrivilegeEscalation: false
                  capabilities:
                    drop:
                      - ALL

Kubewarden

Kubewarden — a CNCF sandbox project sponsored by SUSE — takes yet another approach: policies are compiled to WebAssembly (Wasm) and executed in a sandboxed runtime. This means policies can be written in any language that compiles to Wasm — Rust, Go, TypeScript, C#, or Swift. Kubewarden policies are distributed as OCI artifacts, versioned in container registries alongside application images.

Kubewarden appeals to organizations with polyglot engineering teams or existing policy logic in general-purpose languages. Its Wasm sandbox provides strong isolation guarantees — a malicious or buggy policy cannot crash the admission controller or access cluster resources.

Choosing a Policy Engine

The practical guidance in 2026: if your team is comfortable with Rego and needs maximum policy expressiveness, use Gatekeeper. If your team wants to write policies in familiar Kubernetes YAML and needs built-in image verification, use Kyverno. If you need policies in general-purpose languages or want OCI-based policy distribution, evaluate Kubewarden. Most organizations choose Kyverno for its lower learning curve and broader feature set.

Container Image Scanning and Vulnerability Management

Image scanning has evolved from a CI/CD gate to a continuous lifecycle process. The sheer volume of CVEs — over 29,000 published in 2024, projected to exceed 32,000 in 2025 — makes static scan-and-forget approaches unworkable.

The Scanning Pipeline

A mature image scanning pipeline in 2026 operates at four points:

1. Build time: Scan during CI before pushing to registry. Fail the build for critical and high CVEs with known exploits
2. Registry: Continuous scanning of images at rest. Detect newly published CVEs against previously clean images
3. Admission: Block deployment of images with unresolved critical vulnerabilities via policy engine
4. Runtime: Correlate vulnerabilities with actual package loading to prioritize remediation

Key Tools

Trivy (Aqua) is the dominant open-source scanner, covering OS packages, language dependencies, IaC misconfigurations, Kubernetes manifests, and SBOM generation in a single binary. Its database updates every 6 hours.

Grype (Anchore) provides fast vulnerability scanning focused on container images and filesystems. Paired with Syft for SBOM generation, the Anchore open-source stack covers the full software composition analysis pipeline.

Snyk Container integrates vulnerability scanning into developer workflows with IDE plugins, Git repository scanning, and container registry monitoring. Its developer-first approach — showing fix guidance alongside vulnerability data — reduces mean time to remediation.

Runtime Vulnerability Prioritization

The most important advancement in vulnerability management is runtime-aware prioritization. Not every CVE in a container image is exploitable. A vulnerability in a library that is installed but never loaded into memory poses no practical risk. Sysdig, Aqua, and Wiz all provide runtime profiling that identifies which packages are actually used, allowing security teams to focus remediation on the 5-15% of vulnerabilities that are reachable in the running environment.

Multi-Cluster Security Management

Enterprise Kubernetes deployments in 2026 span dozens to thousands of clusters across multiple cloud providers, regions, and environments. Securing a single cluster is well-understood; maintaining consistent security posture across a fleet is the current challenge.

Fleet-Level Policy Enforcement

Kyverno supports multi-cluster policy distribution through its PolicyReport CRD and integration with GitOps controllers. Policies defined in a central Git repository are synced to all clusters via Argo CD or Flux, with PolicyReports aggregated centrally for compliance dashboards.

Gatekeeper supports policy distribution through its Constraint Framework and external data replication, allowing central policy management with per-cluster customization.

Rancher (SUSE) and Red Hat Advanced Cluster Management (RHACM) provide fleet management with built-in policy engines. RHACM's governance framework can enforce policies across hundreds of clusters with per-cluster compliance status and automated remediation.

Centralized Observability

Multi-cluster security requires centralized visibility. The architecture that works at scale:

• Falco or Tetragon DaemonSets in every cluster, streaming events to a central collector
• Audit logs from every API server flowing to a central SIEM
• Policy violation reports aggregated from Kyverno or Gatekeeper across all clusters
• Vulnerability scan results from registry and runtime scanning correlated in a single dashboard
• RBAC analysis across all clusters to identify privilege sprawl

Tools like Wiz, Prisma Cloud, and Sysdig provide this centralized multi-cluster view out of the box. For open-source stacks, the combination of Falcosidekick, OpenTelemetry Collector, and Grafana provides equivalent visibility with more operational overhead.

Incident Response in Kubernetes Environments

Incident response in Kubernetes is fundamentally different from traditional server-based IR. Containers are ephemeral — by the time you respond to an alert, the compromised pod may have been restarted, rescheduled, or scaled down. Evidence preservation requires different tooling and procedures.

The Kubernetes IR Playbook

Phase 1 — Detection and Triage (0-15 minutes)

1. Receive alert from Falco, Tetragon, or KSPM platform
2. Identify the affected pod, namespace, node, and container image
3. Determine the scope: is this a single pod, a deployment, or a node-level compromise?
4. Check for lateral movement indicators in network policy logs and API server audit logs

Phase 2 — Containment (15-60 minutes)

1. Apply a deny-all NetworkPolicy to the affected namespace or pod
2. Scale the deployment to zero replicas (preserves the ReplicaSet for forensics)
3. If node-level compromise is suspected, cordon and drain the node
4. Rotate any secrets accessible to the compromised workload
5. Revoke the service account token

# Immediate containment
kubectl label pod compromised-pod-xyz quarantine=true
kubectl apply -f deny-all-network-policy.yaml
kubectl scale deployment affected-app --replicas=0 -n production
kubectl cordon node-compromised
kubectl drain node-compromised --ignore-daemonsets --delete-emptydata

Phase 3 — Evidence Collection (1-4 hours)

1. Export container filesystem before termination: kubectl cp or crictl export
2. Collect Falco/Tetragon event logs for the affected pod
3. Pull API server audit logs for the service account and user principals
4. Capture network flow logs from Cilium Hubble or Calico flow logs
5. Export the pod spec, deployment spec, and all associated ConfigMaps/Secrets references
6. Image forensics: pull and analyze the container image layers

Phase 4 — Eradication and Recovery

1. Identify the attack vector (vulnerable image, exposed service, stolen credentials, supply chain)
2. Patch the vulnerability or rotate the compromised credentials
3. Rebuild and re-sign affected container images
4. Redeploy with verified, signed images
5. Verify containment: confirm no persistence mechanisms (CronJobs, DaemonSets, mutating webhooks)

Phase 5 — Lessons Learned

1. Update Falco/Tetragon rules to detect the attack earlier
2. Add policy-as-code rules to prevent the root cause
3. Update network policies to restrict unnecessary access
4. Conduct tabletop exercise with the updated playbook

Forensics Tooling

kubectl-forensics provides automated evidence collection from running or terminated pods. Tracee (Aqua) records detailed syscall traces for forensic analysis. Volatility with container-aware plugins can analyze node memory dumps. Sysdig Capture (the original Sysdig open-source tool) creates full system call recordings that can be replayed offline for analysis.

Real Breach Case Studies and Lessons Learned

Understanding how real attacks succeed is more valuable than any theoretical framework. These cases illustrate the consequences of KSPM failures and the controls that would have prevented them.

Tesla Cryptojacking (2018, Lessons Still Relevant)

What happened: Attackers discovered a Kubernetes dashboard exposed to the internet without authentication. They deployed cryptomining containers across Tesla's AWS Kubernetes cluster, consuming significant compute resources and accessing an S3 bucket containing telemetry data.

Root cause: The Kubernetes dashboard was deployed with default settings — no authentication, no network policy restricting access, and a service account with excessive permissions.

KSPM controls that would have prevented it:

• Network policy restricting dashboard access to internal IPs
• RBAC restricting the dashboard service account to read-only in a limited namespace
• CIS Benchmark check for exposed dashboards (kube-bench would flag this)
• Admission controller blocking privileged containers and unrestricted service accounts

Siloscape — First Known Kubernetes Malware (2021)

What happened: Siloscape exploited Windows container escape vulnerabilities to break out of containers and compromise the underlying Kubernetes node. It then used the node's kubelet credentials to create backdoor deployments across the cluster.

Root cause: Windows container isolation (Hyper-V vs process isolation), combined with overly permissive kubelet credentials and no runtime monitoring.

KSPM controls that would have prevented it:

• Runtime security (Falco/Tetragon) detecting container escape via namespace manipulation
• Node-level least privilege: kubelet credentials scoped to the node's own pods
• Pod Security Standards enforcing restricted profiles
• Network policies preventing lateral movement from compromised nodes

SCARLETEEL Attack Campaign (2023-2024)

What happened: Documented by Sysdig's threat research team, SCARLETEEL attackers compromised Kubernetes clusters through vulnerable web applications, then used the pod's cloud IAM credentials (obtained via the instance metadata service) to escalate from container-level access to cloud-level access. They stole proprietary source code, AWS credentials, and deployed cryptominers.

Root cause: Pods with access to cloud instance metadata service, IAM roles attached to nodes (instead of pods), no egress network policies, and no runtime monitoring.

KSPM controls that would have prevented it:

• Block instance metadata access via network policy or IMDS hop limit
• Use IAM Roles for Service Accounts (IRSA on EKS) or Workload Identity (GKE) instead of node-level IAM roles
• Egress network policies restricting outbound access to known endpoints
• Runtime detection of metadata service access patterns (both Falco and Tetragon have rules for this)
• Image scanning catching the vulnerable web application before deployment

Lessons Across All Breaches

Every Kubernetes breach shares common themes: excessive permissions (RBAC and cloud IAM), missing network segmentation, absent runtime monitoring, and lack of image scanning. No single tool prevents all attacks. KSPM requires defense in depth — overlapping controls that make exploitation difficult and detection rapid.

Building a KSPM Program in 2026

KSPM is not a product you buy — it is a practice you build. The following is a prioritized implementation roadmap for organizations at any maturity level.

Phase 1: Foundations (Weeks 1-4)

1. Enable API server audit logging and ship logs to centralized SIEM
2. Apply default-deny NetworkPolicies in all namespaces
3. Run kube-bench and remediate critical CIS Benchmark failures
4. Enable Pod Security Standards at restricted level with warn mode
5. Deploy Trivy or Grype in CI pipeline to scan images before push

Phase 2: Supply Chain (Weeks 5-8)

1. Implement Sigstore (Cosign) for image signing in CI
2. Deploy Kyverno or Gatekeeper with image verification policies
3. Generate SBOMs with Syft or Trivy and attach to images
4. Configure registry scanning for continuous CVE detection
5. Implement SLSA Level 2 build provenance

Phase 3: Runtime (Weeks 9-12)

1. Deploy Falco or Tetragon DaemonSets with default rulesets
2. Configure alerting to security team channels
3. Implement runtime vulnerability prioritization
4. Deploy Cilium or Calico for layer 7 network policies
5. Integrate External Secrets Operator for secret management

Phase 4: Continuous Compliance (Weeks 13-16)

1. Build policy library covering organizational standards
2. Enable enforcement mode on PSA and policy engines
3. Deploy multi-cluster policy distribution via GitOps
4. Implement automated compliance reporting (CIS, SOC 2, PCI, HIPAA)
5. Conduct first incident response tabletop exercise

Phase 5: Maturity (Ongoing)

1. Runtime-aware vulnerability prioritization across all clusters
2. Automated remediation for known drift patterns
3. Red team exercises targeting Kubernetes infrastructure
4. Chaos engineering with security scenarios
5. Continuous policy refinement based on incident learnings

Conclusion

Kubernetes Security Posture Management in 2026 bears little resemblance to the misconfiguration scanning of 2023. The discipline now encompasses supply chain integrity from source code to runtime, kernel-level observability via eBPF, policy enforcement at every API call, zero-trust networking within the cluster, and continuous compliance against regulatory frameworks.

The tools are mature. Falco and Tetragon provide runtime visibility. Sigstore signs and verifies every artifact. Kyverno and Gatekeeper enforce policies at admission. Cilium secures the network. External Secrets Operator manages credentials. Trivy and Grype scan images. The KSPM platforms from Aqua, Sysdig, Wiz, Prisma Cloud, and ARMO tie it all together.

The remaining gap is not technology — it is implementation discipline. Organizations that treat KSPM as a checkbox exercise will continue to appear in breach reports. Organizations that build layered, enforceable, continuously validated security posture will operate Kubernetes at scale with confidence. The playbook is clear. Execution is what separates secure clusters from the next case study.