Crossplane: Determine desired format for Kubernetes provider secrets

[hasheddan]

What problem are you facing?

Kubernetes cluster connection secrets were previously changed from using the full kubeconfig to only necessary fields for connection in #273. However, #841 expands the use of these secrets to include BYO cluster scenarios, meaning that the secret would be "manually" created. It is not clear whether we want to use the current format given this increased functionality.

How could Crossplane help solve your problem?

Converge on a format that is consistent for all Kubernetes cluster connection secrets. This may not involve any change, but it should be revisited if the BYO cluster scenario proves cumbersome.

[muvaf]

I think our connection string should be raw kubeconfig, which is accepted by all k8s clients I can think of, including kubectl, go-client, controller-runtime, helm etc.

This is especially important when users just want to use Crossplane for infrastructure and deploy the apps on their own, either via helm or some other tool.

[vadasambar]

I am facing an issue where I am able to connect to a GKE provisioned cluster by building rest.Config from connection secrets but I am not able to create a kube config that I can use to install my application using helm. This is a big problem for us because we will have build a kube config in our code to do helm install.

[aeli0]

@hasheddan @muvaf It will be helpful if this issue is fixed. We want to deploy apps only using helm. Do you think it can be prioritized for next release?

[muvaf]

@vadasambar @aeli0 This is implemented across 3 cloud providers and will be included in the next release!

[vadasambar]

Thank you so much @muvaf !