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-2023-29002 — Cilium debug mode logs HTTP headers and TLS keys

HIGH7.2CVE-2023-29002GHSA-pg5p-wwp8-97g8

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

Affected versions

Project	Vulnerable range
Cilium	`1.7, 1.8, 1.9, 1.10, <= 1.11.15, <= 1.12.8, <= 1.13.1`

Patched versions

Project	Fixed in
Cilium	`1.11.16, 1.12.9, 1.13.2`

References

Summary

When run in debug mode, Cilium may log sensitive information. The agent will log the values of HTTP headers if they match HTTP network policy rules. In addition, Cilium 1.12.x before 1.12.9 and 1.13.x before 1.13.2 running in debug mode can log secrets used by the Cilium agent — including TLS private keys for Ingress and GatewayAPI resources, depending on cluster configuration.

Impact

Anything an HTTP-aware policy inspects (including Authorization headers, Cookies, custom auth tokens) ends up in plaintext in the Cilium agent log. On 1.12 / 1.13, TLS private keys for Ingress and GatewayAPI resources are logged at agent restart, when the secrets are modified, and on creation of Ingress or GatewayAPI resources. Anyone with read access to those logs (operators, log aggregators, SIEM tenants, support archives) effectively has the credentials and TLS material they reveal.

Detection

Audit Cilium agent logs from affected versions while debug mode was enabled. Look for HTTP header dumps, references to PEM blocks, and TLS Secret-related log lines around Ingress / GatewayAPI changes. Confirm whether your cluster ran with debug.enabled=true (Helm values) or --debug on cilium-agent.

Mitigation

Upgrade to a patched version: 1.13.2, 1.12.9, or 1.11.16 (or later on the matching line).

Workaround: disable debug mode until upgrade is possible. After upgrade, rotate any TLS keys that were exposed via debug logs on 1.12 / 1.13, and rotate any secrets that may have appeared in HTTP headers logged during the affected period.

Affected versions

Patched versions

References

Summary​

Impact​

Detection​

Mitigation​

References​

Summary

Impact

Detection

Mitigation

References