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-104149 — Cilium ingress host and L7 policies bypassed on nodes with VLAN interface and TCX

HIGH7.2CVE-2026-104149GHSA-vh48-r624-p8v7

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

Affected versions

Project	Vulnerable range
Cilium	`>= 1.18.0, < 1.18.9`
Cilium	`>= 1.17.0, < 1.17.15`
Cilium	`>= 1.16.0, <= 1.16.19`

Patched versions

Project	Fixed in
Cilium	`1.18.9`
Cilium	`1.17.15`

References

GHSA-vh48-r624-p8v7

Summary

On nodes where Cilium is attached to both a VLAN interface and its parent interface, and where TCX attachment is enabled (as is the case on Linux kernel 6.2 and newer), Cilium incorrectly treats packets received on the VLAN interface as having already passed through the proxy or host firewall. This causes ingress host policies and L7 network policies to be skipped for connections arriving from outside the node, allowing otherwise-denied traffic to reach targeted pods.

Impact

An external attacker with the ability to send traffic to pods on affected nodes can bypass ingress host policies and L7 network policies, reaching pods that should otherwise be inaccessible. Same-node pod traffic is not known to be affected. Non-host L3 and L4 policies are not affected. Source-side egress policies, if configured to deny the traffic, may still provide protection. The vulnerability is present on all Cilium v1.16 releases, v1.17.0–v1.17.14, and v1.18.0–v1.18.8 when the described VLAN and TCX conditions are met.

Detection

Identify affected nodes by checking whether Cilium is attached to both a VLAN interface and its parent interface, and whether TCX is enabled (--enable-tcx=true, which is the default on kernel 6.2+). Unexpected ingress traffic reaching pods through a VLAN-attached interface—traffic that should be denied by ingress host or L7 policy—may indicate exploitation. Review Cilium's datapath metrics and Hubble flow logs for policy verdict anomalies on VLAN-attached nodes.

Mitigation

Upgrade Cilium to a patched version:

v1.17.x: upgrade to v1.17.15 or later
v1.18.x: upgrade to v1.18.9 or later

No patch is available for the Cilium v1.16 branch, which has reached end of support. Operators on v1.16 should upgrade to a supported release.

If an immediate upgrade is not possible, apply one of the following workarounds:

Disable TCX by passing --enable-tcx=false as a Cilium agent flag, or setting bpf.enableTCX: false in the Cilium Helm chart.
Depending on cluster configuration and use cases, configure egress policies to mitigate the exposure.

References

GHSA-vh48-r624-p8v7 — GitHub Security Advisory

Affected versions

Patched versions

References

Summary​

Impact​

Detection​

Mitigation​

Related Security Guidance​

References​

Summary

Impact

Detection

Mitigation

Related Security Guidance

References