🌱 feat: Add ClusterProfile provider with credential providers

[hdp617]

Add a ClusterProfile provider with support for credential providers (added in this PR). This provider is based on the kubeconfig provider with the following changes:

• the manager watches for ClusterProfile resources instead of k8s secrets.
• the cluster credentials are generated by the credential providers instead of reading from the secret data.

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: hdp617
Once this PR has been reviewed and has the lgtm label, please assign mjudeikis for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[k8s-ci-robot]

Welcome @hdp617!

It looks like this is your first PR to kubernetes-sigs/multicluster-runtime 🎉. Please refer to our pull request process documentation to help your PR have a smooth ride to approval.

You will be prompted by a bot to use commands during the review process. Do not be afraid to follow the prompts! It is okay to experiment. Here is the bot commands documentation.

You can also check if kubernetes-sigs/multicluster-runtime has its own contribution guidelines.

You may want to refer to our testing guide if you run into trouble with your tests not passing.

If you are having difficulty getting your pull request seen, please follow the recommended escalation practices. Also, for tips and tricks in the contribution process you may want to read the Kubernetes contributor cheat sheet. We want to make sure your contribution gets all the attention it needs!

Thank you, and welcome to Kubernetes. 😃

[embik]

Hi @hdp617, thank you for working on this! As far as I know this seems to be very similar to #48 but implements the new credentials provider functionality. What I like about #48 is that it has more health checks whether a ClusterProfile is marked as healthy.

cc @everpeace. Is there any chance to marry both your work so we don't drop one of the two contributions?

[everpeace]

@embik @hdp617

Is there any chance to marry both your work so we don't drop one of the two contributions?

Thank you for your consideration. I also understand Cluster Inventry API currently supports Secret-based cluster access approach and will support Credential Provider-based approach(not yet merged actually). So, I would be appreciate if we can keep both contributions.

Actually, I recently introduced an abstraction layer for fetching KubeConfig from ClusterProfile in my branch:

multicluster-runtime/providers/cluster-inventory-api/kubeconfigstrategy/interface.go

Lines 16 to 24 in d1e2781

	// Interface defines how the kubeconfig for a cluster profile is managed.
	// It is used to fetch the kubeconfig for a cluster profile.
	type Interface interface {
	// GetKubeConfig is a function that returns the kubeconfig secret for a cluster profile.
	GetKubeConfig(ctx context.Context, cli client.Client, clp *clusterinventoryv1alpha1.ClusterProfile) (*rest.Config, error)
	// CustomWatches can add custom watches to the provider controller
	CustomWatches() []CustomWatch
	}

I believe the abstraction can unify both secret secret-based approach and credential provider-based approach.

So, would you guys mind me trying to merge @hdp617's commit into my branch? Respecting @hdp617 contribution, I will keep him as the author of the merged commit and I will put my name as Co-authored-by:.

[embik]

I'm okay with that approach. @hdp617 WDYT?

[hdp617]

Actually, I recently introduced an abstraction layer for fetching KubeConfig from ClusterProfile in my branch:

multicluster-runtime/providers/cluster-inventory-api/kubeconfigstrategy/interface.go

Lines 16 to 24 in d1e2781

	// Interface defines how the kubeconfig for a cluster profile is managed.
	// It is used to fetch the kubeconfig for a cluster profile.
	type Interface interface {
	// GetKubeConfig is a function that returns the kubeconfig secret for a cluster profile.
	GetKubeConfig(ctx context.Context, cli client.Client, clp *clusterinventoryv1alpha1.ClusterProfile) (*rest.Config, error)
	// CustomWatches can add custom watches to the provider controller
	CustomWatches() []CustomWatch
	}

I believe the abstraction can unify both secret secret-based approach and credential provider-based approach.

I like this. Agreed that this abstraction should work with both models for obtaining cluster credentials.

And merging the commit SGTM. Thank you!