What is Kubernetes security?

Kubernetes security encompasses the practices, tools, and configurations used to protect Kubernetes clusters, workloads, and data. It includes authentication, authorization (RBAC), network policies, pod security standards, secrets management, and runtime security.

What is the CKS certification?

The Certified Kubernetes Security Specialist (CKS) is a CNCF certification that validates expertise in securing Kubernetes clusters. It covers cluster setup and hardening, system hardening, minimizing microservice vulnerabilities, and supply chain security.

What are Kubernetes network policies?

Network policies are Kubernetes resources that control pod-to-pod and pod-to-external traffic. They act as a firewall for your cluster, allowing you to specify which pods can communicate with each other based on labels, namespaces, and ports.

What are Pod Security Standards?

Pod Security Standards (PSS) are predefined security profiles that define different levels of pod security restrictions: Privileged (unrestricted), Baseline (minimally restrictive to prevent known privilege escalations), and Restricted (heavily restricted following security best practices).

What is RBAC in Kubernetes?

Role-Based Access Control (RBAC) is a Kubernetes authorization mechanism that regulates access to resources based on user roles. It uses Role, ClusterRole, RoleBinding, and ClusterRoleBinding resources to define and assign permissions to users and service accounts.

How do I secure etcd in Kubernetes?

Secure etcd by enabling encryption at rest for secrets, using TLS for client-server communication, restricting access to etcd endpoints via firewall rules, enabling authentication, and running regular backups. etcd stores all cluster data including secrets.

What is a container escape attack?

A container escape attack occurs when a process breaks out of container isolation to access the host system or other containers. Common vectors include privileged containers, hostPath mounts, and kernel exploits. Mitigate with Pod Security Standards and seccomp profiles.

What tools are used for Kubernetes security scanning?

Popular Kubernetes security tools include Trivy (vulnerability scanning), Falco (runtime security), kube-bench (CIS benchmarks), OPA Gatekeeper and Kyverno (policy enforcement), Kubescape (security posture), and Cosign (image signing).

GHSA-p58h-r4j3-h5vx — Kyverno cleanup controller nil-policy context escape

CRITICAL9.9GHSA-p58h-r4j3-h5vx

CVSS vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H
Affected projects: kyverno
Disclosed: October 21, 2026
Last updated: October 23, 2026

Affected versions

Project	Vulnerable range
github.com/kyverno/kyverno	`>= 1.17.0, <= 1.19.1`

Patched versions

Project	Fixed in
github.com/kyverno/kyverno	`1.19.2`

References

GHSA-p58h-r4j3-h5vx

Summary

The Kyverno cleanup controller constructs its context loader by passing nil in place of the policy object (ctxFactory(nil, kyvernov1.Rule{})), causing policyNamespace to be set to an empty string. This makes the apiCall URL-path namespace clamp (added for CVE-2026-22039) and the globalReference denial (added for a related fix) inert by construction. A namespaced CleanupPolicy therefore receives none of the namespace confinement that an equivalent namespaced Policy would receive, even though the cleanup controller is enabled by default and the chart grants create cleanuppolicies to every namespace admin.

Impact

A user who can create a CleanupPolicy in any namespace can embed context entries using apiCall or globalReference that reach arbitrary namespaces and global context entries, effectively bypassing the namespace isolation guarantees introduced by the CVE-2026-22039 and related fixes. Because the background controller's privileged ServiceAccount executes the context lookups, the tenant's own RBAC in the victim namespace is not consulted. This enables a namespace-scoped actor to read cross-namespace Kubernetes resources and global context entries, and depending on the context payload, to escalate privileges cluster-wide.

Detection

Audit all CleanupPolicy resources in your cluster for spec.context entries that use apiCall or globalReference. In an unpatched cluster running Kyverno versions 1.17.0 through 1.19.1, any such entries execute without namespace confinement. The Kyverno admission webhook does not block apiCall or globalReference context entries in CleanupPolicy admission, so no admission-time signal exists.

Mitigation

Upgrade Kyverno to version 1.19.2 or later, which passes the correct policy object to the context loader factory and restores namespace confinement for CleanupPolicy context entries. Until an upgrade is possible, restrict create and update permissions on cleanuppolicies.kyverno.io to trusted administrators only, removing the default namespace-admin grant where feasible.

References

GHSA-p58h-r4j3-h5vx — Kyverno cleanup controller context escape — GitHub Security Advisory

Affected versions

Patched versions

References

Summary​

Impact​

Detection​

Mitigation​

Related Security Guidance​

References​

Summary

Impact

Detection

Mitigation

Related Security Guidance

References