The hawtio-operator's ClusterRole grants secrets permissions (create, get, list, update, watch) cluster-wide, exceeding operational needs. Although the operator uses a label-selector cache for optimization, its ServiceAccount token authorizes read access to all Secrets in the cluster, and it bypasses the cache via direct API calls. If an attacker compromises the operator pod, they gain read access to every Secret, including highly sensitive credentials. Red Hat classifies this as an Important severity issue with a CVSS 3.1 score of 8.2 (AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:N). Red Hat advises restricting permissions to namespaced Roles with resourceName restrictions, limiting access to the operator namespace, monitoring audit logs for unusual Secret access, and applying NetworkPolicy restrictions. No official fix or patch is currently available according to the vendor advisory.

Compromise of the hawtio-operator pod allows an attacker to read every Secret in the Kubernetes cluster, including bootstrap tokens, cloud credentials, and other operators' secrets. This can lead to significant confidentiality and integrity breaches across the cluster. The vulnerability requires prior pod compromise but has a cluster-wide blast radius due to excessive permissions granted to the operator's ServiceAccount.

Red Hat recommends scoping permissions to namespaced Roles created on demand for each Hawtio instance, with resourceNames restrictions for the Service CA secret. Restrict access to the hawtio-operator namespace and limit who can exec into the operator pod. Monitor cluster audit logs for unexpected Secret access patterns from the hawtio-operator ServiceAccount. As a defense-in-depth measure, apply a NetworkPolicy to the operator namespace restricting egress to only the Kubernetes API server and required service endpoints. No official patch or fix is currently confirmed; check the vendor advisory for updates.