Every request an agent sends over the gRPC broker is authorized with a
SubjectAccessReview built from the CloudEvent's ce-clustername attribute. Six of
the eight registered services then perform the Kubernetes write against the name
or namespace carried inside the event payload, which the authorizer never looked
at. The two values coincide for every client the project ships, because the
codecs derive ce-clustername from the object being sent. A client that does not
use those codecs can set them independently.
On top of that, the hub performs the write with its own ServiceAccount, so the
ManagedCluster validating webhook authorizes the grpc-server SA rather than the
agent. That SA holds managedclustersets/join cluster-wide.
Together, one registered managed cluster can move itself into any other tenant's
ManagedClusterSet and can overwrite any other cluster's ManagedCluster object.
Your own SELF_ASSESSMENT.md rates the property this breaks as Critical: "This
dedicated namespace 'cluster namespace' cannot be access by other managed
clusters", and "Components running on a managed cluster are restricted to
accessing only their own resources on the hub, preventing unauthorized
interactions between clusters." The gRPC registration enhancement states the same
requirement: "The agent should be authorized by broker to avoid one agent can
consume event messages from other clusters."