Cilium (SDS secret sync for L7 network policies): A tenant confined to their own namespace reaches across and rewrites

Impact

A tenant confined to their own namespace reaches across and rewrites another tenant's L7 policy enforcement. When SDS is enabled for L7 policies, synced Secrets and ConfigMaps land in a shared namespace where names can collide. An attacker who can create a Secret or ConfigMap in their own namespace plus a CiliumNetworkPolicy referencing it picks a name that collides with a victim's object, and their object overwrites the synchronised SDS object the victim's policy depends on — including policies using headerMatches.secret. The result is that the attacker chooses whether another tenant's traffic is permitted or denied: open a path that should be closed, or close one that should be open and take out that tenant's service. Namespace-scoped create rights on ordinary Kubernetes objects is exactly the permission set a GPU cloud hands every customer.

Who can reach it

Adjacent network / in-cluster. Requires namespace-scoped rights to create a Secret or ConfigMap and a referencing CiliumNetworkPolicy, plus knowledge of the victim object's name, on a cluster with SDS enabled for L7 policies.

What to do

Upgrade to Cilium 1.17.18, 1.18.12 or 1.19.6 and roll the agents. Workaround without upgrading: disable policy Secret synchronisation and manage referenced policy Secrets directly in the configured policy-secrets namespace (cilium-secrets by default), which removes the shared naming surface. Audit existing synced objects for unexpected owners.

References