Allows provider kubernetes to respect connection secret settings

[morningspace]

What problem are you facing?

Provider kubernetes is designed to provision and manage Kubernetes objects on (remote) Kubernetes clusters. For a normal Kubernetes object such as a ConfigMap or whatever else, it does not have to define a connection secret, since it does not make sense to use a connection string in order to connect to these Kubernetes objects. For the kubeconfig used to connect to the cluster that these Kubernetes objects reside in, it is handled separately in ProviderConfig using spec. credentials.

However, if the Kubernetes object managed by the provider is something driven by some Kubernetes controller at backend which has more complicated scenario, such as to drive a provisioning of a Kafka instance on the target cluster, then to connect to what is actually provisioned by the Kubernetes object may need some connection string, e.g. the connection string to access the Kafka instance.

Right now, the provider does not write any connection secret by itself. So, if I specify spec.writeConnectionSecretToRef, a connection secret with empty data will be created, which is not expected.

How could Crossplane help solve your problem?

To allow provider kubernetes to respect the connection settings by creating the corresponding secret would help in this case. Not like other providers, the provider kubernetes itself may not know how to build such connection string, but in case the whatever backend that drives the actual workload provisioning knows that and create the secret, then the provider may have a way that can allows user to specify where to retrieve this string, e.g.: via an optional field called spec.readConnectionSecretToRef, then expose it to Object resource using spec.writeConnectionSecretToRef.

[morningspace]

cc @turkenh

[turkenh]

I believe we can just implement the following here: crossplane-contrib/provider-helm#73

[turkenh]

This is how it looks like at the end: https://github.com/crossplane-contrib/provider-helm/blob/e49c3e791f5c7bd95d50ab0762297daeb084c459/examples/sample/release.yaml#L36

[morningspace]

That is awesome! It is exactly what we need. Then I think we could add that as a TODO for this provider!

[st3v]

We're also interested in this feature.

@turkenh, I tried your suggestion and replicated what you had done for provider-helm. That seems to work well. If you want to try it out, I pushed a quick-and-dirty, non-tested version of this to ghcr.io/st3v/provider-kubernetes:master.

Anyway, I wanted to check if you're still open to adding this feature and whether the approach you suggested above still makes sense to you. If so, we would be happy to work on a proper PR for this.

[turkenh]

I wanted to check if you're still open to adding this feature and whether the approach you suggested above still makes sense to you

@st3v yes, feel free to open a PR. Thanks!