VPA Admission Webhook Supports TLS 1.0 and TLS 1.1

[nairb774]

Which component are you using?:

vertical-pod-autoscaler

What version of the component are you using?:

Component version: v0.10.0

Note: By inspection, this issue looks to exist on the current HEAD as well.

What k8s version are you using (kubectl version)?:

kubectl version: 1.22 EKS Output

$ kubectl version
WARNING: This version information is deprecated and will be replaced with the output from kubectl version --short.  Use --output=yaml|json to get the full version.
Client Version: version.Info{Major:"1", Minor:"26", GitVersion:"v1.26.3", GitCommit:"9e644106593f3f4aa98f8a84b23db5fa378900bd", GitTreeState:"archive", BuildDate:"2023-03-19T19:47:22Z", GoVersion:"go1.19.7", Compiler:"gc", Platform:"linux/amd64"}
Kustomize Version: v4.5.7
Server Version: version.Info{Major:"1", Minor:"22+", GitVersion:"v1.22.17-eks-48e63af", GitCommit:"47b89ea2caa1f7958bc6539d6865820c86b4bf60", GitTreeState:"clean", BuildDate:"2023-01-24T09:34:06Z", GoVersion:"go1.16.15", Compiler:"gc", Platform:"linux/amd64"}
WARNING: version difference between client (1.26) and server (1.22) exceeds the supported minor version skew of +/-1

What environment is this in?:

AWS EKS 1.22

What did you expect to happen?:

Semi-modern security best practices.

What happened instead?:

The Vertical pod autoscaler's admissions controller is using the Go server default of TLS 1.0 (docs code use).

How to reproduce it (as minimally and precisely as possible):

The issue was identified using the tool testssl.sh. Which indicates that the TLS 1.0 and TLS 1.1 protocols are available. The recommendation I've been told is that it would be preferred to only support TLS1.2 and better. While I wasn't provided the exact reasoning, a cursory search about TLS 1.0 and TLS 1.1 seems to indicate that the protocols are vulnerable to various downgrade attacks among other issues.

Sample ./testssl.sh --protocols 127.0.0.1:8000 output from a v0.10.0 instance

$ ./testssl.sh --protocols 127.0.0.1:8000
###########################################################

testssl.sh       3.0.8 from https://testssl.sh/

(abdd51d 2022-09-28 09:19:37)
  This program is free software. Distribution and
         modification under GPLv2 permitted.
  USAGE w/o ANY WARRANTY. USE IT AT YOUR OWN RISK!

   Please file bugs @ https://testssl.sh/bugs/

###########################################################
Using "OpenSSL 1.0.2-bad (1.0.2k-dev)" [~179 ciphers]

on 5edb70630a50:./bin/openssl.Linux.x86_64

(built: "Sep  1 14:03:44 2022", platform: "linux-x86_64")
Start 2023-04-25 09:04:29        -->> 127.0.0.1:8000 (127.0.0.1) <<--
rDNS (127.0.0.1):       localhost.

Service detected:       HTTP
Testing protocols via sockets except NPN+ALPN
SSLv2      not offered (OK)

SSLv3      not offered (OK)

TLS 1      offered (deprecated)

TLS 1.1    offered (deprecated)

TLS 1.2    offered (OK)

TLS 1.3    offered (OK): final

NPN/SPDY   not offered

ALPN/HTTP2 h2, http/1.1 (offered)
Done 2023-04-25 09:04:49 [  25s] -->> 127.0.0.1:8000 (127.0.0.1) <<--

Anything else we need to know?:

I am by no means an expert in this area, and am not any more qualified to provide advice in this area than your average internet blogger. I was also not provided a very clear recommendation from the reporter as what might be acceptable. That being said, my hope is that by bringing this to light, it might be possible to being in an appropriate expert from the larger Kubernetes ecosystem to give more precise guidance.

[jbartosik]

Thanks, that would be a good thing to fix

[a-hilaly]

/assign

[Shubham82]

closing this issue, as this issue is resolved in the following PR: #5803

/close

[k8s-ci-robot]

@Shubham82: Closing this issue.

In response to this:

closing this issue, as this issue is resolved in the following PR: #5803

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.