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-4789 — Kyverno CEL http.Get/http.Post SSRF in NamespacedValidatingPolicy

HIGH8.5CVE-2026-4789GHSA-rggm-jjmc-3394

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

Affected versions

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

Patched versions

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

References

Summary

A Server-Side Request Forgery (SSRF) vulnerability in Kyverno's CEL HTTP library (pkg/cel/libs/http/) allows users with namespace-scoped policy creation permissions to make arbitrary HTTP requests from the Kyverno admission controller. This enables unauthorized access to internal services in other namespaces, cloud metadata endpoints (169.254.169.254), and data exfiltration via policy error messages.

Impact

http.Get() and http.Post() available in CEL-based policies (policies.kyverno.io API group) do not enforce any URL restrictions. Unlike resource.Lib, which enforces namespace boundaries for namespaced policies, http.Lib allows unrestricted access to any URL. A user with namespace-scoped permission to create NamespacedValidatingPolicy can:

Reach internal services in other namespaces (cross-namespace data access)
Hit the cloud instance metadata service at 169.254.169.254 to harvest IAM credentials issued to the cluster nodes
Exfiltrate response bodies via the policy's validation error messages

This is a different code path from related apiCall issues (CVE-2026-22039, CVE-2026-41323, CVE-2026-40868) — those targeted pkg/engine/apicall/, while this is in pkg/cel/libs/http/http.go.

Detection

Audit NamespacedValidatingPolicy and policies.kyverno.io resources for CEL expressions invoking http.Get(...) or http.Post(...). Treat any external URL or any URL pointing at 169.254.169.254, metadata.google.internal, or in-cluster services in other namespaces as a strong signal.

Pair with audit-log review and egress-log review for outbound HTTP from the Kyverno admission controller pod to unexpected destinations during the affected window.

Mitigation

Upgrade Kyverno to v1.16.4 or later.

Workarounds until patched:

Restrict who can create or update NamespacedValidatingPolicy and other policies.kyverno.io resources via tight RBAC.
Block egress from the kyverno namespace to the cloud metadata service via NetworkPolicy (169.254.169.254 and fd00:ec2::254).
If CEL http.Get/http.Post is not used, consider disabling the policies.kyverno.io CRD set on affected versions.

Affected versions

Patched versions

References

Summary​

Impact​

Detection​

Mitigation​

References​

Summary

Impact

Detection

Mitigation

References