How to remediate SSL Medium Strength Cipher Suites Supported (SWEET32) Vulnerability in Tanzu Kubernetes Grid
Article ID: 378116
Updated On:
Products
Issue/Introduction
This KB will help to remediate below mentioned vulnerabilities reported in control plane and worker nodes in TKGm 2.2.0
ubuntu@jumpbox:~$ nmap --script ssl-enum-ciphers -p 31234 10.X.X.X
Starting Nmap 7.80 ( https://nmap.org ) at 2024-09-20 06:14 UTC
Nmap scan report for 10.X.X.X
Host is up (0.0025s latency).
PORT STATE SERVICE
31234/tcp open unknown
| ssl-enum-ciphers:
| TLSv1.2:
| ciphers:
| TLS_RSA_WITH_AES_128_GCM_SHA256 (rsa 2048) - A
| TLS_RSA_WITH_AES_256_GCM_SHA384 (rsa 2048) - A
| TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
| TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
| TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C
| compressors:
| NULL
| cipher preference: server
| warnings:
| 64-bit block cipher 3DES vulnerable to SWEET32 attack
| Forward Secrecy not supported by any cipher
|_ least strength: C
Nmap done: 1 IP address (1 host up) scanned in 0.46 seconds
Note: The preceding log excerpts are only examples. Date, time, and environmental variables may vary depending on your environment.
Environment
VMware Tanzu Kubernetes Grid
Tanzu Kubernetes Grid
Resolution
1) Take a backup of below certificates
ubuntu@jumpbox:~$ k get certificate -A | egrep -i 'pinn|dex'
pinniped-supervisor pinniped-cert True pinniped-supervisor-default-tls-certificate 98s
tanzu-system-auth dex-cert True dex-cert-tls 99s
2) Create two new certificates using the backup file taken in the step (1)
NOTE - Keep the "metadata.name" same as original values , for example - "cert-custom" and name of the "spec.secretName" same as well , for example - "cert-tls-custom"
- Add the privateKey section under spec
privateKey:
algorithm: ECDSA
size: 256
For example -
# dex-cert-custom
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
name: cert-custom
namespace: tanzu-system-auth
spec:
commonName: tkg-dex
dnsNames:
- tkg-dex.com
duration: 2160h0m0s
ipAddresses:
- 10.X.X.X
issuerRef:
group: cert-manager.io
kind: Issuer
name: dex-ca-issuer
renewBefore: 360h0m0s
secretName: cert-tls-custom
usages:
- server auth
- client auth
privateKey:
algorithm: ECDSA
size: 256
# pinniped-cert-custom
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
name: cert-custom
namespace: pinniped-supervisor
spec:
commonName: tkg-pinniped
duration: 2160h0m0s
ipAddresses:
- 10.X.X.X
issuerRef:
group: cert-manager.io
kind: Issuer
name: pinniped-ca-issuer
renewBefore: 360h0m0s
secretName: cert-tls-custom
usages:
- server auth
- client auth
privateKey:
algorithm: ECDSA
size: 256
3) Create both the certificates using yaml created in Step (2)
kubectl apply -f <filename>
4) Verify "cert-tls-custom" and "cert-custom" secrets are created under both "pinniped-supervisor" and "tanzu-system-auth" namespace.
5) Get the "values.yaml" from pinniped package
kubectl get secret -n $NS $PKG_NAME-package -o jsonpath="{.data.values\.yaml}" | base64 -d > values.yaml
6) Change or add the key custom_tls_secret: "cert-tls-custom" to the "values.yaml"
7) Patch the pinniped package secret
kubectl patch secret $PKG_NAME-package -n $NS -p "{\"data\":{\"values.yaml\":\"$(base64 -w 0 < values.yaml)\"}}" --type=merge
8) Verify that vulnerability warning does not appear anymore
nmap --script ssl-enum-ciphers -p 31234 10.X.X.Xubuntu@jumpbox:~$ nmap --script ssl-enum-ciphers -p 31234 10.X.X.X
Starting Nmap 7.80 ( https://nmap.org ) at 2024-09-24 10:03 UTC
Nmap scan report for 10.X.X.X
Host is up (0.0022s latency).
PORT STATE SERVICE
31234/tcp open unknown
Nmap done: 1 IP address (1 host up) scanned in 0.41 seconds
Note: The preceding log excerpts are only examples. Date, time, and environmental variables may vary depending on your environment.
Feedback
