[bug] Regression: can't use dockerconfigjson Secret for HelmRepository authentication since 1.1.0

[artem-nefedov]

Since release of source-controller 1.1.0 (flux 2.1.0), we see a problem preventing HelmRepository from being reconciled with an error:

✗ HelmRepository reconciliation failed: 'failed to construct Helm client's TLS config: cannot use secret 'secretname' to construct TLS config: invalid secret type: 'kubernetes.io/dockerconfigjson''

We only use secretRef to provide authentication, the Secret doesn't have any TLS-related contents.
Secret in question has is of type "kubernetes.io/dockerconfigjson", and has 3 data fields: .dockerconfigjson, username, and password.
HelmRepository is of regular indexed type (not OCI).

Furthermore, the help for --secret-ref option of flux create source helm command still shows that it can be a docker secret:

      --secret-ref string   the name of an existing secret containing TLS, basic auth or docker-config credentials

[aryan9600]

Does switching the Secret to type: Opaque resolve this issue?

[artem-nefedov]

@aryan9600 I tested it, and yes, type: Opaque works.
But that isn't really a good solution for us, since we use same Secret as imagePullSecret for Pods, as well as secretRef for OCIRepository objects, and would rather keep it that way.
And it was working well since flux 0.x.x times all the way until flux 2.1.0.

[makkes]

The long-term solution should really be to change the type of your Secret to Opaque as aryan9600 suggested. Why? It is pretty uncommon to use a Secret of type kubernetes.io/dockerconfigjson for anything but serving a JSON-serialized docker config file in the .dockerconfigjson field and it is not unlikely that Flux won't support your particular Secret of that type for long.

[artem-nefedov]

@makkes Even if that's the case, I would at least expect such changes to be explicitly listed as "breaking changes", because it was functionality that was provided before, but isn't anymore.

And the fact that --secret-ref help in cli still shows that secret can be "docker-config credentials" also doesn't help.

[makkes]

Yes, I'm not disputing this. It was clearly an oversight on our side.