You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
The text was updated successfully, but these errors were encountered: