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-q825-p383-r9v5 — Kyverno legacy apiCall executor bypasses SSRF blocklist

HIGH7.6GHSA-q825-p383-r9v5

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

Affected versions

Project	Vulnerable range
github.com/kyverno/kyverno	`< 1.19.1`

Patched versions

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

References

GHSA-q825-p383-r9v5

Summary

Kyverno's April 2026 SSRF blocklist — which denies outbound requests to 169.254.169.254, 169.254.169.253, metadata.google.internal, 127.0.0.0/8, and ::1/128 — was wired exclusively into the new CEL http.Get/Post library. The legacy apiCall service executor used by every classic ClusterPolicy/Policy context[].apiCall.service call and every GlobalContextEntry external-API call received no equivalent filtering. A ClusterPolicy or GlobalContextEntry author can therefore drive Kyverno to issue requests to the cloud metadata endpoint or any in-cluster service, and Kyverno's projected ServiceAccount token is attached to those requests unconditionally.

Impact

Any principal with permission to create or update ClusterPolicy, Policy, or GlobalContextEntry resources can exploit this vulnerability to reach the cloud instance metadata service at 169.254.169.254, read cloud credentials, and access in-cluster services using Kyverno's network position. Additionally, Kyverno's projected ServiceAccount token is sent to the attacker-chosen host on every such request, constituting a credential egress even where direct exploitation of cloud metadata is not possible. Because URL templating allows a policy to derive the service URL from the admission resource under review, a lower-privileged resource submitter may also trigger the exfiltration depending on how the policy is constructed.

Detection

Audit all ClusterPolicy, Policy, and GlobalContextEntry resources in the cluster for context[].apiCall.service entries with url fields pointing to private or metadata IP ranges (169.254.0.0/16, 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16). Review Kyverno controller logs for unexpected outbound HTTP requests to these ranges. Any GlobalContextEntry resource whose apiCall.service.url is not the in-cluster Kubernetes API server should be treated as suspicious on unpatched versions.

Mitigation

Upgrade to Kyverno 1.19.1, which applies the SSRF host/CIDR blocklist and ServiceAccount token destination check to the legacy apiCall service executor and the GlobalContextEntry external-API path, matching the controls already in place for the CEL http.Get/Post path. Prior to upgrading, restrict ClusterPolicy, Policy, and GlobalContextEntry create/update permissions to trusted administrators using RBAC, and review existing resources for suspicious service.url values.

References

GHSA-q825-p383-r9v5 — Kyverno Security Advisory

Affected versions

Patched versions

References

Summary​

Impact​

Detection​

Mitigation​

Related Security Guidance​

References​

Summary

Impact

Detection

Mitigation

Related Security Guidance

References