Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Merged
merged 1 commit into from
Sep 7, 2023

Conversation

aryan9600
Copy link
Member

@aryan9600 aryan9600 commented Aug 31, 2023

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

@aryan9600 aryan9600 marked this pull request as ready for review August 31, 2023 10:25
internal/controller/helmrepository_controller_test.go Outdated Show resolved Hide resolved
internal/tls/config.go Outdated Show resolved Hide resolved
@aryan9600 aryan9600 added the backport:release/v1.1.x To be backported to release/v1.1.x label Aug 31, 2023
Copy link
Member

@makkes makkes left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

@@ -111,6 +105,20 @@ func Test_tlsClientConfigFromSecret(t *testing.T) {
}
}

func TestKubeTLSConfigFromSecret(t *testing.T) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

@souleb souleb left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM.

@darkowlzz
Copy link
Contributor

darkowlzz commented Sep 1, 2023

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
Copy link
Member Author

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
Copy link
Contributor

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
Copy link
Member

makkes commented Sep 1, 2023

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.

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

Introduce `LegacyTLSClientConfigFromSecret` which does not check the
Secret type while constructing the TLS config.

Signed-off-by: Sanskar Jaiswal <jaiswalsanskar078@gmail.com>
Copy link
Contributor

@darkowlzz darkowlzz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM!

@aryan9600 aryan9600 merged commit d516627 into main Sep 7, 2023
@aryan9600 aryan9600 deleted the fix-helm-tls branch September 7, 2023 07:48
@fluxcdbot
Copy link
Member

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
backport:release/v1.1.x To be backported to release/v1.1.x
Projects
None yet
Development

Successfully merging this pull request may close these issues.

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