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-fmqp-4wfc-w3v7 — Kyverno APICall SSRF breaks multi-tenant isolation

HIGH7.7GHSA-fmqp-4wfc-w3v7

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 13, 2026
Last updated: April 28, 2026

Affected versions

Project	Vulnerable range
kyverno	`< 1.16.2`

Patched versions

Project	Fixed in
kyverno	`1.16.2`

References

GHSA-fmqp-4wfc-w3v7

Summary

Kyverno's APICall feature allows policies to fetch external data via HTTP requests, but the implementation does not validate the target URL before executing the request. This creates a Server-Side Request Forgery (SSRF) vulnerability that any user with Policy creation permissions can exploit. Because Kyverno executes all APICall requests using a cluster-wide high-privilege ServiceAccount, a low-privilege tenant can direct Kyverno to access resources across tenant boundaries — a classic Confused Deputy problem. Sensitive data retrieved by Kyverno, such as Secrets from other namespaces or cloud IAM credentials from a metadata service, can be surfaced to the attacker via PolicyReport resources.

Impact

Users with only namespace-level Policy creation permissions can exploit this vulnerability to access internal Kubernetes resources across tenant boundaries, retrieve cloud platform IAM credentials from link-local metadata endpoints (such as the AWS IMDS at 169.254.169.254), and read Secrets belonging to other namespaces. This completely breaks tenant isolation in multi-tenant Kubernetes environments. The vulnerability does not require cluster-admin privileges. Exfiltrated data is returned to the attacker through PolicyReport resources that Kyverno writes as part of normal policy evaluation.

Detection

Review all Policy and ClusterPolicy resources in the cluster for apiCall.service.url fields referencing IP addresses, link-local ranges (169.254.x.x), loopback addresses, or unexpectedly internal services. Audit PolicyReport and ClusterPolicyReport resources for response content that does not originate from trusted external services. In multi-tenant environments, pay particular attention to PolicyReports created by low-privilege namespaces that contain data from other namespaces or cloud metadata endpoints.

Mitigation

Upgrade Kyverno to 1.16.2 or later, which adds URL validation to the apiCall HTTP execution path. Mitigate the risk on unpatched versions by restricting Policy creation permissions (kyverno.io/v1 Policy and ClusterPolicy resources) so that only trusted administrators can create policies with apiCall.service.url references. Implement network egress controls on the Kyverno controller pods to restrict outbound connections to an approved allowlist of endpoints, preventing requests to internal metadata services and cross-tenant Kubernetes services. In multi-tenant clusters, treat any tenant's ability to create Kyverno policies with apiCall.service.url as cluster-wide access until Kyverno 1.16.2 or later is deployed.

References

GHSA-fmqp-4wfc-w3v7

Affected versions

Patched versions

References

Summary​

Impact​

Detection​

Mitigation​

References​

Summary

Impact

Detection

Mitigation

References