Kite dashboard: any authenticated user can read cluster overview data for clusters they cannot access

Impact

The overview route is registered before Kite's RBAC middleware and GetOverview only checks that the caller has at least one role, so an authenticated user can set the x-cluster-name header to any cluster Kite fronts and receive its aggregate Kubernetes inventory and capacity data. The result is read-only disclosure across a boundary the dashboard is supposed to enforce. For an operator running one Kite instance over several clusters, this leaks node counts, capacity and workload inventory of production or other-customer clusters to anyone holding the lowest-privilege dashboard login, which is exactly the reconnaissance a later attack starts from. No write access and no credential disclosure is described.

Who can reach it

Any authenticated Kite user, regardless of role, sending a request to /api/v1/overview with the x-cluster-name header set to a cluster outside their permissions. Network reach to the dashboard plus a valid login is all that is needed.

What to do

Upgrade Kite to 0.12.3, which moves the route behind the RBAC middleware. This is a dashboard deployment upgrade: roll the Kite pod, no cluster or GPU node disruption. Until then, either run one Kite instance per trust boundary instead of one instance over many clusters, or block /api/v1/overview at the ingress or proxy in front of Kite. Treat any inventory data the dashboard exposed to low-privilege users as already disclosed.

References