Database/Container, Kubernetes & orchestration
Submariner operator: long-lived broker service account token exposed in the Submariner CR
Impact
The operator stores a long-lived broker service account bearer token in the Submariner custom resource spec, where it is readable by anything that can kubectl get the CR or reach the cluster's etcd data - including etcd backups, which are usually held to a much weaker standard than Secrets. Red Hat states the token grants full control of the mesh network, letting the holder manage endpoints and secrets. On a multi-cluster GPU fleet Submariner is the thing stitching cluster and tenant networks together, so control of it means the ability to redirect or observe cross-cluster traffic between training clusters and storage. Because the token is long-lived, exposure does not expire on its own.
Who can reach it
Any authenticated principal with read access to the Submariner CR in its namespace, or with access to the cluster's etcd database or an etcd backup. No exploit chain beyond reading the object.
What to do
The record does not name a fixed build - track Red Hat's CVE page and the Bugzilla entry for the Advanced Cluster Management 2.x errata. In the meantime, treat the token as disclosed to anyone who has ever had read access: rotate the broker service account credential, and tighten RBAC so ordinary cluster users cannot read Submariner CRs. Also review who can restore or read etcd backups.
References
This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.