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-2024-37307 — Cilium bugtool leaks TLS keys and Kafka API keys

HIGH7.9CVE-2024-37307GHSA-wh78-7948-358j

CVSS vector: CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:N
Affected projects: cilium
Disclosed: June 13, 2024
Last updated: April 27, 2026

Affected versions

Project	Vulnerable range
cilium-bugtool	`>= 1.13.0, < 1.13.16`
cilium-bugtool	`>= 1.14.0, < 1.14.12`
cilium-bugtool	`>= 1.15.0, < 1.15.6`

Patched versions

Project	Fixed in
cilium-bugtool	`1.13.17`
cilium-bugtool	`1.14.12`
cilium-bugtool	`1.15.6`

References

Summary

The output of cilium-bugtool with the --envoy-dump flag set can contain sensitive data when run against Cilium deployments with the Envoy proxy enabled. Affected features include TLS inspection, Ingress with TLS termination, Gateway API with TLS termination, and Kafka network policies with API key filtering. The sensitive data covers CA certificates, certificate chains, private keys used by Cilium HTTP network policies and Ingress / Gateway API, and API keys used in Kafka-related network policy.

Impact

cilium-bugtool is a debugging tool typically invoked manually and does not run during normal cluster operation. However, archives produced with --envoy-dump from a cluster running Envoy expose secrets that the cluster operator likely treats as private — TLS private keys grant impersonation of TLS endpoints terminated by Cilium, and Kafka API keys grant access to topics protected by API-key-aware network policies. Any archive shared externally (uploaded to a ticket, sent to a vendor, or stored in shared cloud storage) should be treated as a credential disclosure.

Detection

Audit any previously-shared bugtool archives produced with --envoy-dump from Cilium clusters with Envoy enabled. Confirm whether your cluster runs Envoy and which features (TLS inspection, Ingress, Gateway API, Kafka network policies) are in use, since those determine which categories of secrets were exposed.

Mitigation

Upgrade to a patched version on the appropriate release line:

Cilium v1.15.6 or later (for the 1.15 line)
Cilium v1.14.12 or later (for the 1.14 line)
Cilium v1.13.17 or later (for the 1.13 line)

There is no workaround for the underlying issue. Operators who have previously shared --envoy-dump archives from Envoy-enabled clusters should rotate the affected TLS certificates and private keys, regenerate Ingress / Gateway API TLS material, and rotate any Kafka API keys configured in Kafka network policies.

Affected versions

Patched versions

References

Summary​

Impact​

Detection​

Mitigation​

References​

Summary

Impact

Detection

Mitigation

References