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

CVE-2026-41068 — Kyverno ConfigMap loader cross-namespace read bypasses RBAC

HIGH7.7CVE-2026-41068GHSA-cvq5-hhx3-f99p

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

Affected versions

Project	Vulnerable range
github.com/kyverno/kyverno	`<= 1.17.1`

References

Summary

CVE-2026-22039 fixed cross-namespace privilege escalation in Kyverno's apiCall context by validating the URLPath field. However, the ConfigMap context loader has the identical vulnerability — the configMap.namespace field accepts any namespace with zero validation, allowing a namespace admin to read ConfigMaps from any namespace using Kyverno's privileged service account. This is a complete RBAC bypass in multi-tenant Kubernetes clusters.

Impact

	CVE-2026-22039 (fixed)	This vulnerability
Location	`apiCall.URLPath` field	`configMap.namespace` field
Validation	Namespace regex check	None

The exploit chain:

Namespace admin creates a Kyverno Policy in their namespace using standard RBAC.
Policy uses context.configMap.namespace: "victim-ns" to reference another namespace.
Kyverno's admission controller SA (which has cluster-wide view rights) fetches the ConfigMap.
The policy mutates a trigger ConfigMap to exfiltrate the stolen data via annotations.

In multi-tenant clusters where namespace boundaries are the security perimeter, this trivially defeats that perimeter for every ConfigMap in the cluster.

Detection

Audit Policy and ClusterPolicy resources whose context block uses configMap.namespace referencing a namespace other than the policy's own. Anything outside the same-namespace pattern is the affected primitive.

Pair with audit-log review for unexpected get/list actions on ConfigMaps in sensitive namespaces (kube-system, namespaces hosting tenant-private workloads) issued by the Kyverno admission controller's SA.

Mitigation

Upgrade Kyverno to v1.17.2 or later. v1.17.2 also includes the patch for the related apiCall confused-deputy issue (CVE-2026-41323, CVE-2026-40868) — upgrade once, mitigate three.

Workarounds until patched:

Restrict who can create or update Kyverno Policy resources via tight RBAC, especially in shared / multi-tenant clusters.
Audit existing policies for cross-namespace configMap.namespace references and remove them.
Where feasible, prefer CEL-based policies that do not rely on the affected context loaders.

Affected versions

References

Summary​

Impact​

Detection​

Mitigation​

References​

Summary

Impact

Detection

Mitigation

References