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-7p2q-4xvg-vxc6 — istiod DoS via ServiceEntry Waypoint Address

HIGH7.7GHSA-7p2q-4xvg-vxc6

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

Affected versions

Project	Vulnerable range
istio.io/istio	`>= 1.29.0, < 1.29.9`
istio.io/istio	`>= 1.30.0, < 1.30.6`
istio.io/istio	`>= 1.31.0, < 1.31.2`

Patched versions

Project	Fixed in
istio.io/istio	`1.29.9`
istio.io/istio	`1.30.6`
istio.io/istio	`1.31.2`

References

GHSA-7p2q-4xvg-vxc6

Summary

In Istio ambient mode, istiod resolves an IP-addressed waypoint's owning service by (network, IP) with no namespace in the lookup key. The EDS shim uses krt.FetchOne over the ServicesByAddress index; when two services share the same address, it panics with "FetchOne found for more than 1 item" on a krt goroutine and takes istiod down. A ServiceEntry with spec.addresses set to a waypoint's ClusterIP — in any namespace — creates this collision and istiod crash-loops until the ServiceEntry is deleted. A tenant with permission to create ServiceEntry resources in their own namespace can cross namespace boundaries to crash istiod for the entire mesh.

Impact

A low-privilege tenant who has create on ServiceEntry resources in their own namespace can cause istiod to crash and enter a crash-loop by creating a single ServiceEntry whose spec.addresses matches the ClusterIP of an IP-addressed waypoint in another namespace. Config distribution and certificate rotation stall mesh-wide for the duration of the outage. The denial of service persists until a cluster administrator deletes the offending ServiceEntry. This vulnerability affects only deployments running Istio in ambient mode with IP-addressed waypoints; hostname-addressed waypoints (the default) are not affected.

Detection

Monitor istiod logs for panic messages containing "FetchOne found for more than 1 item". If istiod is restarting repeatedly while ambient mode is enabled, investigate ServiceEntry resources across all namespaces for entries whose spec.addresses overlap with waypoint ClusterIPs. Run the following to list all ServiceEntry resources and their addresses for comparison against waypoint ClusterIPs:

kubectl get serviceentry --all-namespaces -o jsonpath='{range .items[*]}{.metadata.namespace}/{.metadata.name}: {.spec.addresses}{"\n"}{end}'

Mitigation

Upgrade Istio to 1.29.9, 1.30.6, or 1.31.2. If an immediate upgrade is not possible, apply one of the following workarounds: delete the colliding ServiceEntry; restrict who may create ServiceEntry resources using RBAC; or avoid IP-addressed waypoints by relying on hostname-addressed waypoints, which istiod resolves by name rather than by IP and are not vulnerable to this collision.

References

GHSA-7p2q-4xvg-vxc6 — Istio Security Advisory

Affected versions

Patched versions

References

Summary​

Impact​

Detection​

Mitigation​

Related Security Guidance​

References​

Summary

Impact

Detection

Mitigation

Related Security Guidance

References