OpenChoreo cluster gateway: unauthenticated internal listener exposes cross-tenant secrets and pod exec

Impact

The cluster-gateway server published its proxy, exec and wirelog endpoints on an internal listener with no client certificate and no token check, so anything that can route to that listener speaks to every connected data plane as the gateway does. That yields reads of tenant Kubernetes Secrets, mutation of workloads, and command execution inside pods across all attached clusters. On a shared GPU fleet the Secrets alone typically carry registry pulls, model-store credentials and cloud tokens, and exec into a neighbouring tenant's pod puts an attacker on the same node and the same GPUs as that tenant's work. The blast radius is the set of data planes the gateway federates, not a single namespace.

Who can reach it

Any caller that can reach the gateway's internal listener - an adjacent network, another pod on the cluster network, or a misrouted service exposure. No client certificate and no token are required by the vulnerable code path.

What to do

Upgrade to OpenChoreo 1.0.3, 1.1.3, or 1.2.0-rc.2 and roll the cluster-gateway deployment; this is a control-plane component restart, no GPU node drain. Until the upgrade lands, restrict network reachability of the internal listener to the components that legitimately call it and treat any Secrets reachable through connected data planes as candidates for rotation.

References