raphasle
commented
20 hours ago After seeing and reading https://github.com/crossplane/crossplane/blob/main/design/one-pager-package-image-config.md, it makes probably more sense to support the new pkg.crossplane.io/v1alpha1 ImageConfig API.
What problem are you facing?
Pulling charts from a private repository is possible by using forProvider.chart.pullSecretRef which points to a secret containing username and password to pull the chart. This is simple and perfectly understandable when reading the documentation or the source code, and it makes sense when looking at the underlying pull action. However, this is IMO not intuitive from a user's perspective (the person writing the composition). Furthermore, limiting to only one pullSecretRef makes migrations harder (e.g. when the Helm chart moves from one private registry to another, the username and pw in the secret must be updated at the same time the new compositions as part of a Configuration Package are released).
How could Crossplane help solve your problem?
It would be more intuitive if the helm provider uses ImagePullSecrets as it is e.g. the case how images are pulled before starting a pod. PullSecretRef would ideally also support secrets of type kubernetes.io/dockerconfigjson (which can contain multiple credentials). Furthermore, it would be even nicer when the helm provider would use the ImagePullSecrets of its own service account when no pullSecretRef is specified and the chart cannot be pulled without credentials. This would allow assigning an ImagePullSecret (that most likely anyways already exists in the cluster for other purposes) to the crossplane service account (of which the helm provider service account will inherit the ImagePullSecret) without having to create a secret with registry credentials specifically for the crossplane helm provider.