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-77531 — Cilium secret sync name collision enables cross-namespace L7 policy bypass

HIGH7.3CVE-2026-77531GHSA-xqhm-7xhv-6ppj

CVSS vector: CVSS:3.1/AV:A/AC:H/PR:H/UI:N/S:C/C:H/I:H/A:N
Affected projects: cilium
Disclosed: August 12, 2026
Last updated: August 20, 2026

Affected versions

Project	Vulnerable range
github.com/cilium/cilium	`< v1.17.18`
github.com/cilium/cilium	`>= v1.18.0, < 1.18.12`
github.com/cilium/cilium	`>= v1.19.0, < 1.19.6`

Patched versions

Project	Fixed in
github.com/cilium/cilium	`v1.17.18`
github.com/cilium/cilium	`v1.18.12`
github.com/cilium/cilium	`v1.19.6`

References

GHSA-xqhm-7xhv-6ppj

Summary

In Cilium clusters with the Secret Discovery Service (SDS) enabled for L7 network policies, an attacker may exploit name collisions between synced Secret and ConfigMap objects to affect policy enforcement behavior. A namespaced attacker who can create a Secret or ConfigMap and a referencing CiliumNetworkPolicy may choose object names that collide with a victim object, allowing the attacker-controlled object to overwrite the synchronized SDS object used by the victim policy, including policies using headerMatches.secret. This can result in unauthorized traffic being permitted or legitimate traffic being denied.

Impact

A namespaced attacker with privileges to create Secrets or ConfigMaps and CiliumNetworkPolicy objects can overwrite the SDS objects used by victim policies in other namespaces. This allows the attacker to change policy enforcement behavior—permitting traffic that should be denied, or denying traffic that should be allowed. Only clusters with SDS enabled for L7 network policies are affected. The adjacency-scoped (AV:A) and high-privilege (PR:H) requirements constrain exploitability to privileged, network-adjacent actors in the cluster.

Detection

Review Cilium audit logs for unexpected SDS secret synchronization events. Monitor the cilium-secrets namespace for Secret objects whose names match policy-referenced secrets from other namespaces. Inspect CiliumNetworkPolicy objects that use headerMatches.secret references and verify that referenced secret names are unique and not reproducible by tenant namespaces. Unexpected policy behavior changes—traffic unexpectedly allowed or denied—should prompt investigation of synchronized SDS objects.

Mitigation

Upgrade Cilium to a patched version:

v1.17.x: upgrade to v1.17.18 or later
v1.18.x: upgrade to v1.18.12 or later
v1.19.x: upgrade to v1.19.6 or later

As a workaround, operators can mitigate the SDS name collision by disabling policy Secret synchronization and managing referenced policy Secrets directly in the configured policy secrets namespace (cilium-secrets by default), rather than relying on Cilium to sync them from tenant namespaces.

References

GHSA-xqhm-7xhv-6ppj — GitHub Security Advisory

Affected versions

Patched versions

References

Summary​

Impact​

Detection​

Mitigation​

Related Security Guidance​

References​

Summary

Impact

Detection

Mitigation

Related Security Guidance

References