Create Connection Secrets

[crossplane-contrib]

Create Connection Secrets

[turkenh]

This sounds like a good idea which could easily be implemented if we limit connection secret to contain only some remote secret content. This could help for syncing back username and password in the given example but not for hostname.

However, to support hostname as well, we would need to support reading arbitrary resources back (e.g. ip of loadbalancer type service), not only secrets which would require some more work where we would need to define some API to specify which field of which resource to read and store with which key in connection secret.

Something like:

apiVersion: helm.crossplane.io/v1alpha1
kind: Release
metadata:
  name: mariadb-example
spec:
  connectionDetails:
    - apiVersion: v1
      kind: Secret
      name: mariadb-example
      namespace: mariadb
    - apiVersion: v1
      kind: Service
      name: mariadb-example
      namespace: mariadb
      fieldPath: status.loadBalancer.ingress[0].ip
      toConnectionSecretKey: hostname
  writeConnectionSecretToRef:
    name: mariadb-conn
    namespace: crossplane-system
  forProvider:
    ...

[turkenh]

@negz I agree with what you are saying in terms of this being a common need across all providers managing kubernetes workloads and originally I was thinking this functionality should be part of a (yet-to-be-implemented) provider-kubernetes in the form of an observe only resource.

However, having this functionality natively in provider helm as mentioned above also has some value like:

• Using provider helm without additional dependency (e.g. provider-kubernetes)
• Using Release objects individually (e.g. not being part of composition) as mentioned by @srueg above
• Consuming what is deployed with that Release instance without additional CRs

As an analogy, we have GKECluster resource which publishes connection details of the cluster it creates. Having a GKEClusterObservation resource to read connection details of an already existing cluster should not necessarily mean; we should not be publishing connection secrets in GKECluster resource and always rely on GKEClusterObservation to consume the cluster.

I feel like satisfying this common need in the form of reusable code instead (i.e. part of crossplane-runtime), would make more sense considering above. Then, we could still introduce an observe-only managed resource as part of provider-kubernetes by re-using common code or reuse that implementation in provider-kustomize later to have native support.

What do you think about having this functionality in crossplane-runtime?

[turkenh]

I thought about this too, but we'd still need to get the actual state from the cluster and not just from the metadata. Otherwise things like the externalIP of a LoadBalancer service couldn't be retrieved.

Yeah, definitely. I meant only validating whether asked resource is part of the release or not via Release manifest.
If valid, we will fetch actual state on the cluster and return value from there.

[srueg]

We could also work with crossplane/crossplane#1722 to "read" the state? It would require to have an "observeOnly" variant for arbitrary Kubernetes resources though...
Having said that, it would only work when using the Release as part of a Composition, I guess. So it might make sense to have this functionality native in provider-helm.

[negz]

Something like

@turkenh I like the look of this API, though I wonder whether it belongs in provider-helm, as opposed to a distinct provider. I imagine that if we were to write a provider-kustomize for example we'd want the same functionality and a similar API there. I suppose we could just repeat the same pattern in provider-kustomize, but I wonder if there's a case for a generic managed resource that just exposes a connection secret derived from some other Kubernetes resource - e.g. one that Crossplane doesn't manage. 🤔

This does start to sound a lot like the "observe only" resources, but scoped specifically to observing Kubernetes resources which is a bit more of a manageable problem given all the machinery we have for working with the Kubernetes API.

[negz]

@turkenh I see your point, though it does feel a bit strange that the Release resource can seemingly ask for anything in the cluster (whether it be part of the release or not) to be included in its connection secret. 🤔

[turkenh]

@negz yes I feel same about being able to ask for anything independent about Release resource.

I think we can fix this by just limiting what could be asked to the resources only deployed with the release. This should be technically possible since we have access to release metadata which contains manifests for deployed object.

[srueg]

I think we can fix this by just limiting what could be asked to the resources only deployed with the release. This should be technically possible since we have access to release metadata which contains manifests for deployed object.

I thought about this too, but we'd still need to get the actual state from the cluster and not just from the metadata. Otherwise things like the externalIP of a LoadBalancer service couldn't be retrieved.