For an addon to run in hosted mode, it needs a kubeconfig secret for the HostedCluster available on the hosting cluster.

When an Addon is created in hosted mode on the hub, you specify a namespace to be used on the hosting cluster (hosting cluster is specified as an annotation). 

In the namespace on the hosting cluster we need to create a secret with the kubeconfig for the hosted cluster. This secret has a fixed name:

work-manager: work-manager-managed-kubeconfig

policy-config: config-policy-controller-managed-kubeconfig

The kubeadmin secret generated by the HostedCluster resource (control plane) on the hosting cluster, and copy that to the cluster's add-on namespace on the hosting cluster.  This is usually the cluster's name, with the suffix -agent-addon. When the add-on is defined on the hub, you need to make sure to specify the same namespace for the add-on in its spec.

That's it.  Eventually we should create and manage a ServiceAccount, Role and Binding for EACH addon but that is outside the scope.

This is the onboarding document that details how these work: https://docs.google.com/document/d/13NPcFrQAYe4ar9uC_a7hEQ4jVUS-q8HT2Q4t5lmXd0Q/edit