Add authentication method for Gardener Shoot Clusters

[Avarei]

What problem are you facing?

I would like to manage freshly created Gardener Shoot Clusters in this provider. While Most Cluster Management Tools give a AdminKubeConfig, which can be used for setting up permissions for other users and groups - Gardener uses short lived AdminKubeConfigs that are made by creating a subresource on the Shoot Object in the “Seed” cluster.

How could Crossplane help solve your problem?

The Provider could use a Seed KubeConfig to dynamically request and cache the kubeconfig for a referenced shoot cluster.

I would love to implement and contribute this feature if you are open to it.

[j2L4e]

@Avarei I've been looking to solve the same thing. Is maintaining this in a fork what you went for in the end or did you choose a different path?

[Avarei]

@j2L4e sadly I had to prioritize other tasks above managing gardener from crossplane. I hope to get back to it early next year but for the moment I don't have the capacity.

Back then I was not really sure how actively I should push for this change, since it uses the providerConfig fields in quite an unusual/different way.
The kubeconfig contains the credentials to the seed-cluster, instead of the actual target cluster and the identity section contains a secretRef which just contains a reference to the actual cluster to use.

I also thought of an alternative approach that might be a good substitute.
The idea is to create a Disposable Request in provider-http.
it could create the kubeconfig secret and refresh it automatically.
sadly it also needs a PR to work, since provider-http needs mTLS support to work with the kubernetes API.
If this sounds interesting, take a look at crossplane-contrib/provider-http#21

[j2L4e]

Frankly, having provider-kubernetes depend on gardener/gardener for this rather specific use-case, doesn't feel quite right.
Using provider-http to reconcile ProviderConfigs for provider-kubernetes much better aligns with how you would handle kubeconfigs coming from other cluster-providers.
Thanks for linking the mtls-issue, I'll look into that!

Edit: Got it working using provider-http, token auth instead of certs and insecureSkipTLSVerify. Which is good enough for a POC. Thanks for the hint, @Avarei.