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-59v6-2x73-wfg4 — globalcontext.Lib unconfined in Kyverno namespaced policies

HIGH7.7GHSA-59v6-2x73-wfg4

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: September 10, 2026
Last updated: October 24, 2026

Affected versions

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

Patched versions

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

References

GHSA-59v6-2x73-wfg4

Summary

Kyverno's CEL policy compiler registers several libraries for policy authors. For namespaced policy types (which tenants can author in their own namespace), each library that can reach data outside the policy's namespace is passed the policy namespace as a confinement argument. globalcontext.Lib is the one exception: it is registered without a namespace or any derivative of one, meaning it performs no tenant-namespace scoping. A tenant with NamespacedValidatingPolicy create permissions in their own namespace can call globalContext.get("<entry>", "") and receive the full cached contents of any cluster-scoped GlobalContextEntry — including data pulled from namespaces the tenant has no RBAC permission to read. The same unconfined registration also appears in the mpol, dpol, gpol, background-controller, and image-verification evaluator compilers.

Impact

A tenant authorized only in their own namespace can read sensitive data cached in GlobalContextEntry resources from any namespace in the cluster. GlobalContextEntry is cluster-scoped by design and is used to cache data retrieved from external APIs or Kubernetes resources across all namespaces. Depending on what administrators have configured as GlobalContextEntry data sources, an exploiting tenant could read secrets, configuration, or other sensitive state from namespaces they do not control. The three previously fixed advisories for this same pattern (GHSA-8p9x-46gm-qfx2, GHSA-cvq5-hhx3-f99p, GHSA-rggm-jjmc-3394) confirm the severity and exploitability of namespace confinement gaps in Kyverno's CEL library registration.

Detection

Enumerate all NamespacedValidatingPolicy (and sibling NamespacedMutatingPolicy, NamespacedDeletingPolicy, NamespacedGeneratingPolicy, NamespacedImageValidatingPolicy) resources in the cluster and search their CEL expressions for calls to globalContext.get(). On unpatched versions (1.16.0 through 1.18.x), any such call succeeds without namespace restriction. Review Kyverno audit logs for unusual policy evaluation patterns that correlate with globalContext.get() calls from namespaced policies authored by non-administrative tenants.

Mitigation

Upgrade to Kyverno 1.19.1, which passes the policy's namespace to globalcontext.Lib at registration time — matching the confinement already applied to resource.Lib and http.Lib. Until the upgrade is complete, restrict creation and update of NamespacedValidatingPolicy and sibling namespaced policy types to trusted administrators using RBAC, removing the ability for unprivileged tenants to author policies that call globalContext.get().

References

GHSA-59v6-2x73-wfg4 — Kyverno Security Advisory

Affected versions

Patched versions

References

Summary​

Impact​

Detection​

Mitigation​

Related Security Guidance​

References​

Summary

Impact

Detection

Mitigation

Related Security Guidance

References