Support alternative registration style in gloo-fed skv2 "RegisterCluster"

[Ido-Itz]

Version

1.10.x

Is your feature request related to a problem? Please describe.

We want to use a more secure method to create the necessary trust between gloo-fed and the remote cluster. Specifically, not storing static Kubeconfig access tokens.

Describe the solution you'd like

Currently the gloo-fed skv2 module will perform the following as part of the “RegisterCluster” flow:

1. Creating a ServiceAccount on the remote cluster.
2. Binding RBAC Roles/ClusterRoles to said ServiceAccount
3. And finally creating a Kubeconfig Secret with the BearerToken of the remote ServiceAccount

This behavior assumes that we want to use a service account in the other cluster for this communication, and that we are ok with a static token in the stored Kubeconfig for this new service account. In our flow, we want to use a dynamically generated BearerToken that represents a User from an OIDC provider which the remote cluster trusts. We then bind the Roles and ClusterRoles to this user in the remote cluster, and not to a service account. The Kubeconfig which we provide for the registration flow uses the users.exec.command field to generate a dynamic token as part of the k8s-client creation process (See https://kubernetes.io/docs/reference/access-authn-authz/authentication/#client-go-credential-plugins

In order to support this for ourselves we had to stop using the existing "RegisterCluster" function in the skv2 lib and implement our own, which performs:

1. Create remote RBAC Roles/ClusterRoles (and the remote namespace for these Roles)
2. Bind these to a User of our choice (not a service-account)
3. Copy a provided Kubeconfig secret (with no hardcoded token) of our choice to the gloo-fed namespace, for gloo-fed to use for federation.
4. Create the KubernetesCluster resource

Is it possible that the existing "RegisterCluster" function will be modified to support this flow as well as the existing one? Or perhaps an alternative RegisterClusterExternalOIDC function?

Describe alternatives you've considered

Implementing an alternative RegisterCluster method ourselves, which we did. However, this is a type of "fork" from the existing registration behavior, and we would prefer to avoid maintaining it with new gloo/gloo-fed versions.

Additional Context

Thanks!

[github-actions[bot]]

This issue has been marked as stale because of no activity in the last 180 days. It will be closed in the next 180 days unless it is tagged "no stalebot" or other activity occurs.