Database/Container, Kubernetes & orchestration
Cilium (mutual authentication, TLS certificate chain handling): Mutual authentication, the control an operator turns on
Impact
Mutual authentication, the control an operator turns on precisely to get cryptographic workload identity between tenants, can be defeated by anyone holding any valid client certificate. The attacker obtains the target identity's public certificate — public by construction — appends it to their own chain during the TLS handshake, and Cilium accepts them as that identity. Every policy decision keyed on mutual auth then evaluates against the impersonated workload. In a shared GPU cluster this means a low-value pod in one tenant's namespace can present as another tenant's service and reach whatever that service is allowed to reach: model registries, feature stores, training data endpoints, control-plane APIs. The failure is total rather than partial, and the feature is beta and already slated for deprecation, so operators who adopted it for tenant separation should assume it never provided the boundary they scoped it for.
Who can reach it
Adjacent network, from inside the cluster. The attacker needs any valid client certificate issued in the mesh plus the target identity's public certificate. Only clusters with Cilium mutual authentication enabled are affected.
What to do
Upgrade to Cilium 1.19.6, 1.18.12 or 1.17.18 and roll the agent DaemonSet. There is no workaround short of upgrading. Given the feature is deprecated, plan the migration off mutual authentication onto a boundary you intend to keep, and in the meantime do not count mutual auth as the control separating tenants in your threat model or your customer-facing claims.
References
This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.