OpenChoreo cluster-gateway lacks caller authentication, enabling critical Kubernetes API exploits

According to the GitHub Security Advisory database, OpenChoreo's cluster-gateway internal proxy has been identified as critically vulnerable due to the absence of caller authentication and enforcement of read-only restrictions. The internal management APIs exposed by the cluster-gateway, including `/api/proxy/`, `/api/exec/`, and `/api/wirelogs/`, allow tunneled requests to connected data planes' Kubernetes APIs without requiring client certificates or tokens for authentication. This design flaw enables unauthorized parties with network access to the internal listener to read Secrets from tenant namespaces, modify or delete workloads, and execute commands inside pods across all connected data planes. The advisory notes that only Secrets in the `kube-system` namespace are blocked, leaving other sensitive data such as database credentials and TLS private keys exposed.

Operators should carefully assess the network isolation of the cluster-gateway's internal listener before upgrading or deploying OpenChoreo. Specifically, they should verify that the internal port is not reachable by untrusted workloads or external actors and enforce restrictive NetworkPolicies to limit access. Failure to secure the listener could result in unauthorized access to the Kubernetes API across all connected data planes, leading to potential data breaches, workload tampering, or pod-level command execution. This vulnerability highlights the importance of implementing robust authentication and authorization mechanisms for internal APIs, a recurring pattern in security advisories across similar projects.