Summary
Authenticated Kite users with any role can request /api/v1/overview for a cluster that their roles do not permit by selecting that cluster with x-cluster-name. The overview route is registered before middleware.RBACMiddleware() and GetOverview only checks len(user.Roles) > 0, so it returns aggregate Kubernetes inventory and capacity data from unauthorized clusters.
The issue is present on current main commit 38c9bb9d4b746c0d2a8252f3c35cdfa07ab01c21 and latest release v0.12.2 at commit 0aae35abb2d6a8adf623fe60349261aa48753ccc.
Impact
A low-privileged user who only has access to one cluster can set x-cluster-name to another configured cluster and retrieve aggregate inventory and resource sizing data for that cluster. The response includes total node, pod, namespace, service, CPU, and memory values. This bypasses the cluster membership boundary used elsewhere in Kite.
The validated impact is confidentiality only. I did not prove Kubernetes mutation, pod names, secret values, kubeconfig contents, or bearer token exposure through this endpoint.
Technical details
routes.go registers /api/v1/overview before the global RBAC middleware is applied:
routes.go:131-133: /api/v1 gets RequireAuth() and ClusterMiddleware(cm).
routes.go:135: /api/v1/overview is registered.
routes.go:171: api.Use(middleware.RBACMiddleware()) is applied only after overview and several other routes are registered.
pkg/middleware/cluster.go:21-40 accepts the target cluster name from x-cluster-name, query, or cookie and injects the matching ClientSet without checking whether the user can access that cluster.
retrieves the selected cluster and user, but only rejects users with zero roles: