fix(webhook): disable tsl 1.0 and 1.1 on webhook service

[ChanYiLin]

ref: longhorn/longhorn#8387

Follow the same implementation in Harvester to disable tls 1.0 and 1.1 on webhook service

[c3y1huang]

I've run the sslscan on both v1.6.1 and the master branch clusters.

Interestingly, there is a difference in the results without applying the fix in this PR.

In v1.6.1, as described, TLSv1.0 and TLSv1.1 shows enabled:

> k -n longhorn-system get daemonsets.apps longhorn-manager -o yaml | grep image:
        image: longhornio/longhorn-manager:v1.6.1
   
> k get service -n longhorn-system | grep admission
longhorn-admission-webhook    ClusterIP   10.43.18.107    <none>        9502/TCP       2m17s

> k -n longhorn-system exec -it longhorn-manager-j9pdl -- sslscan 10.43.18.107:9502
Version: 2.0.16
OpenSSL 1.1.1l-fips  24 Aug 2021 SUSE release 150500.17.25.1

Connected to 10.43.18.107

Testing SSL server 10.43.18.107 on port 9502 using SNI name 10.43.18.107

  SSL/TLS Protocols:
SSLv2     disabled
SSLv3     disabled
TLSv1.0   enabled
TLSv1.1   enabled
TLSv1.2   enabled
TLSv1.3   enabled

However, on the master branch, TLSv1.0 and TLSv1.1 shows disabled (without this PR):

> k -n longhorn-system get daemonsets.apps longhorn-manager -o yaml | grep image:
        image: longhornio/longhorn-manager:master-head
    
> k get service -n longhorn-system | grep admission
longhorn-admission-webhook    ClusterIP   10.43.213.78    <none>        9502/TCP       39s

> k -n longhorn-system exec -it longhorn-manager-8ltwk -- sslscan 10.43.213.78:9502
Version: 2.0.16
OpenSSL 1.1.1w-fips  11 Sep 2023 SUSE release 150600.2.11

Connected to 10.43.213.78

Testing SSL server 10.43.213.78 on port 9502 using SNI name 10.43.213.78

  SSL/TLS Protocols:
SSLv2     disabled
SSLv3     disabled
TLSv1.0   disabled
TLSv1.1   disabled
TLSv1.2   enabled
TLSv1.3   enabled

So, I have 2 questions:

1. What is the cause of the different outcomes when the cluster is running with the master-head?
2. Is the purpose of this fix to address versions before v1.7? If so, is this fix intentionally implemented on the master branch?

[c3y1huang]

Apart from the questions, the fix LGTM if the intention is to backport and introduce a whitelist approach.

[ChanYiLin]

Hi @c3y1huang
I found the reason.
Because in v1.6.1, we use go 1.21, and the default MinVersion=1.0
Golang community update the MinVersion to 1.2 in go 1.22 here

So for the second question,
we have to backport the fix by specifying the minVersion in the config.

cc @derekbit

[c3y1huang]

Hi @c3y1huang I found the reason. Because in v1.6.1, we use go 1.21, and the default MinVersion=1.0 Golang community update the MinVersion to 1.2 in go 1.22 here

So for the second question, we have to backport the fix by specifying the minVersion in the config.

If I understand correctly, updating to Go version 1.22 should resolve this issue. Is there any reason we are implementing a whitelist and the minVersion instead of updating the go version? Seems we've already done so in the master and 1.5.x branches.

[c3y1huang]

Hmm. mergify already merged this. @ChanYiLin please check to see if golang version upgrade is sufficient. If it is, I think we don't need this PR.

cc @derekbit

[derekbit]

Hmm. mergify already merged this. @ChanYiLin please check to see if golang version upgrade is sufficient. If it is, I think we don't need this PR.

cc @derekbit

@ChanYiLin Feel free to revert the PR if @c3y1huang's comment is valid. Thank you.

[derekbit]

Hi @c3y1huang I found the reason. Because in v1.6.1, we use go 1.21, and the default MinVersion=1.0 Golang community update the MinVersion to 1.2 in go 1.22 here
So for the second question, we have to backport the fix by specifying the minVersion in the config.

If I understand correctly, updating to Go version 1.22 should resolve this issue. Is there any reason we are implementing a whitelist and the minVersion instead of updating the go version? Seems we've already done so in the master and 1.5.x branches.

BTW, we need to update v1.6.x's golang version.
https://github.com/longhorn/longhorn-manager/blob/v1.6.x/go.mod#L3

[c3y1huang]

BTW, we need to update v1.6.x's golang version. https://github.com/longhorn/longhorn-manager/blob/v1.6.x/go.mod#L3

#2774