Description

A flaw was found in insights-client. The component's ServiceAccount is bound to a ClusterRole granting cluster-wide secrets get, list, and watch permissions, while the code only requires access to a single specific Secret. This excessive privilege means that a compromise of the insights-client pod or ServiceAccount token would grant an attacker read access to all Secrets across the hub cluster, including managed-cluster kubeconfigs and other sensitive credentials.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "6.5",
  "pubDate": "2026-08-12T22:17:16.143Z",
  "pubdate": "2026-08-12T22:17:16.143Z",
  "executiveSummary": "A privilege configuration flaw exists in insights-client where its associated ServiceAccount is bound to an overly permissive ClusterRole.\nThe vulnerability grants cluster-wide get, list, and watch permissions on Kubernetes Secrets, whereas the application logic only requires access to a single specific Secret.\nThis excessive privilege architecture introduces severe risk implications, allowing an unauthorized actor who compromises the insights-client pod or acquires its ServiceAccount token to escalate privileges and gain read access to all Secrets across the entire hub cluster.\nImpacted systems include deployments utilizing insights-client with the default over-scoped Role-Based Access Control (RBAC) configurations.\nAttacker capabilities resulting from successful exploitation include the unauthorized extraction of sensitive credentials, managed-cluster kubeconfigs, and other critical cluster secrets.\nExploitation requirements rely upon initial access to the insights-client pod or compromise of its authentication tokens, enabling attackers to leverage the overly broad ClusterRole permissions assigned to the ServiceAccount.",
  "technicalDetails": "The root cause of this vulnerability is an overly broad RBAC configuration associated with the insights-client component.\nSpecifically, the ServiceAccount utilized by insights-client is bound to a ClusterRole that explicitly permits the verbs get, list, and watch on the core API group resources designated as secrets.\nHowever, the operational source code of insights-client is designed to interact exclusively with a single, designated Secret rather than querying arbitrary cluster-wide resources.\nThis violates the principle of least privilege, creating a stark mismatch between the application's actual operational requirements and its assigned Kubernetes authorization boundary.\nThe step-by-step attack flow begins when an adversary achieves initial access to the insights-client pod via an application-layer vulnerability, container escape, or misconfiguration.\nOnce execution is achieved within the pod context, the attacker extracts the projected ServiceAccount token typically mounted at /var/run/secrets/kubernetes.io/serviceaccount/token.\nUsing this compromised token, the attacker interacts directly with the Kubernetes API server, authenticating as the insights-client ServiceAccount.\nBecause the ServiceAccount is backed by a cluster-wide ClusterRole granting secrets read permissions, the API server authorizes requests to list and watch all Secrets across all namespaces in the hub cluster.\nPost-exploitation impact includes the mass harvesting of sensitive credentials, cryptographic keys, API tokens, and managed-cluster kubeconfigs stored within cluster secrets.\nThis unauthorized disclosure effectively compromises the confidentiality of the entire hub cluster and potentially connected managed clusters, facilitating lateral movement and further compromise."
}