add min TLS version for stream server

[snstaberah]

Signed-off-by: snstaberah yangyonglc@inspur.com

What type of PR is this?

/kind feature

What this PR does / why we need it:
add MinVersion: tls.VersionTLS12 in streamserver，this can improve security of cloudcore，and pass some security test
Which issue(s) this PR fixes:

Fixes #3753

Special notes for your reviewer:

Does this PR introduce a user-facing change?:

NONE

[fisherxu]

Stream server is used to serve the connection from apiserver, not sure whether the logs/exec works if adding this?

[snstaberah]

I did a test on kubernetes 1.20.9 and kubeedge 1.8.1，logs/exec works well；
In fact，apiserver use client-go to get a TLSConfig，and client-go also define the TLS min version to 1.2 for security；

[fisherxu]

Sorry for the delay, the MinVersion looks good, but for the CipherSuites, in kubeedge we use the ECDSA keys, so only set one tls.TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, not sure if it's correct for k8s, myabe k8s can use rsa keys.

[snstaberah]

I read kubernetes apiserver code（client-side）and kubelet code （server-side） for logs/exec，in kubernetes，kubelet can use a flag to define tls-cipher-suites（https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/），and apiserver didn't set cipher-suites in client request tls config，so apiserver will use default go lib (crypto/tls) cipher suite list to compare with server side；

to keep consistent with kubelet，we can just use default tls cipher suite config for stream server to receive request from apiserver, I have modified my commit and did a test on kubernetes 1.20.9 and kubeedge 1.8.1，logs/exec works well;

but in practice，kubelet often set only one or two prefered cipher suite to improve security，less than the default cipher suite list，so i think it is better to add a flag for streamserver to let user chose a cipher suite in the future；

this has no effect for the apiserver to request stream server because apiserver didn't set cipher-suites in client request ，so it can use a full list to dial with stream server；

[fisherxu]

@snstaberah Thanks for the explanation! Looks good to use the default value in go. I found in my cluster installed by kubeadm, the kubelet haven't set the cipher-suite flag, so wondering the pic showed above is your cluster?

[fisherxu]

Now for the cipher-suite in kubeedge cloud-edge connection, we only set one is tls.TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, which means we can't compatible the rsa certs, but we support user to set their own certs. So do you think it's needed to add tls.TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 in the list?

Another point I read from the docs is in tls1.3, it's not needed to set the cipher-suite...

[snstaberah]

in my company，we set both apiserver and kubelet
with TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384，according to this link https://www.ibm.com/docs/en/cloud-private/3.1.2?topic=installation-specifying-tls-ciphers-etcd-kubernetes，to fix SSL Medium Strength Cipher Suites Supported(SWEET32) problem；there are some similar reference with https://docs.openshift.com/container-platform/4.8/nodes/nodes/nodes-nodes-tls.html；
it is special config for TLS1.2；
if we support user to set their own certs， to connect from edgecore to tunnel server，i think add tls.TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 in the tunnel server cipher suite list，or add a flag in cloudcore for user to set their prefered cipher suite is better；

[fisherxu]

Agreed. And now the best choice for cipher suite seems is ECDHE_ECDSA, with more short key and high security ;-)

[fisherxu]

/lgtm
/approve

[kubeedge-bot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: fisherxu

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [fisherxu]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment