helmrepo: fix Secret type check for TLS via .spec.secretRef

[aryan9600]

This is a fix for a regression introduced in a302c71 which would wrongly check for the type of the Secret specified in .spec.secretRef while configuring TLS data.

This introduces a new function that skips the Secret type check and uses that for HTTP HelmRepository TLS.

Fixes #1218

[makkes]

The code seems to be a little convoluted that's why I needed some time to understand how the change actually fixes the issue but now I'm 99% sure it does. Good job.

[makkes]

If you want to go above and beyond, I'd suggest to add a test for TLSClientConfigFromSecret to make sure it doesn't fail as it did before.

[souleb]

LGTM.

[darkowlzz]

I'd like to understand to what level are we walking back with this change. As I see it and also pointed out when we were introducing the breaking behavior, this is not limited to HelmRepository but also affects all the other APIs that had a similar change, OCIRepository, image-reflector-controller ImageRepository and notification-controller Provider. The difference being, except for HelmRepository, other APIs had a separate field for TLS secret in .spec.certSecretRef but before the recent change, they all accepted any type of secret. The recent change introduced the restriction to require any TLS data to be only provided via secrets of type opaque, tls and "" (empty type).
But this change now reverts that restriction only for HelmRepository where the TLS data exists in .spec.secretRef. If we are walking back and reverting this breaking change, why don't we revert it for others too?
Similar to #1218 , if someone was using a docker config secret with OCIRepository for both secret and cert secret, it's still a breaking change for them. Is HelmRepository an exception?

[aryan9600]

Is HelmRepository an exception?

yeah, pretty much (at least thats my understanding). in general, the Secret specified in .spec.certSecretRef should be of type Opaque or kubernetes.io/tls. enforcing this type check for the Secret specified in .spec.secretRef was a regression and hence is being reverted.

[darkowlzz]

It seems like this situation can be interpreted in different ways.

the Secret specified in .spec.certSecretRef should be of type Opaque or kubernetes.io/tls. enforcing this type check for the Secret specified in .spec.secretRef was a regression and hence is being reverted.

If this reasoning sounds good to others, I'm okay with that. But I think this reasoning is trying to justify a limitation of the current implementation. The reason type check is being performed on an auth secret is because the code in https://github.com/fluxcd/source-controller/blob/v1.1.0/internal/helm/getter/client_opts.go#L118-L121 isn't checking if the given secret contains any TLS data and passing it to a function whose purpose is to parse and build TLS config. The regression in #1218 can be simply addressed by just adding a check to see if the auth secret contains TLS data before trying to construct TLS config from it. Something like the following:

diff --git a/internal/helm/getter/client_opts.go b/internal/helm/getter/client_opts.go                                                                                       
index 4e77f29..412bd68 100644                                                                                                                                                
--- a/internal/helm/getter/client_opts.go                                                                                                                                    
+++ b/internal/helm/getter/client_opts.go
@@ -115,9 +115,11 @@ func GetClientOpts(ctx context.Context, c client.Client, obj *helmv1.HelmReposit
                }
                hrOpts.GetterOpts = append(hrOpts.GetterOpts, opts...)
  
-               // If the TLS config is nil, i.e. one couldn't be constructed using `.spec.certSecretRef`
-               // then try to use `.spec.secretRef`.
-               if hrOpts.TlsConfig == nil && !ociRepo {
+               // If the TLS config is nil, i.e. one couldn't be constructed using
+               // `.spec.certSecretRef`, and if the secret contains TLS data then try to
+               // use `.spec.secretRef`.
+               if hrOpts.TlsConfig == nil && !ociRepo &&
+                       len(authSecret.Data["certFile"])+len(authSecret.Data["keyFile"])+len(authSecret.Data["caFile"]) != 0 {
                        hrOpts.TlsConfig, tlsBytes, err = stls.TLSClientConfigFromSecret(*authSecret, url)
                        if err != nil {
                                return nil, "", fmt.Errorf("failed to construct Helm client's TLS config: %w", err)

Creating differences in TLSClientConfigFromSecret() and KubeTLSClientConfigFromSecret() for this doesn't seem like a good design choice when both have exactly the same purpose. Introduces inconsistencies when things can remain simple. One argument could be that TLSClientConfigFromSecret() always gets called after KubeTLSClientConfigFromSecret(), so all the necessary validation always gets performed, but I think that's a bad design. We don't need to do that. They should be usable independently, regardless of one is for deprecated keys.

Removing the secret type restriction only for HelmRepository introduces inconsistencies that can be avoided by keeping things as they are. Nowhere in Flux do we accept TLS data from a Secret type that's not one of the three we expect.

[makkes]

I tend to agree with Sunny here. When the user references a Secret in certSecretRef it's clear that the Secret should contain the expected 3 fields. Adding a type check for the Secret does seem like a duplicate verification that's unnecessary. The fact that Kubernetes has a type field doesn't necessarily mean that we should consume it.

[darkowlzz]

LGTM!

[fluxcdbot]

Successfully created backport PR for release/v1.1.x:

• [release/v1.1.x] helmrepo: fix Secret type check for TLS via .spec.secretRef #1225