More about K8s medium-strength ciphers and Kube Scheduler

Last year, I wrote about how I was able to mitigate a medium-strength ciphers warning against the cube-scheduler component of IBM Cloud Private ( a Kubernetes distribution ): -

Mitigating "SSL Medium Strength Cipher Suites Supported" warnings from Nessus scans

I did a little bit more with this yesterday on a Red Hat Linux box.

This was the warning that our Nessus box threw up: -

The remote host supports the use of SSL ciphers that offer medium strength encryption, which we currently regard as those with key lengths at least 56 bits and less than 112 bits.

against port 10259 of our host.

I used this command: -

netstat -aonp|grep 10259 

to work out which process was using that particular port: -

tcp6       0      0 :::10259                :::*                    LISTEN      23860/hyperkube      off (0.00/0/0)

and then used: -

ps auxw | grep 23860

to check the specific process, which verified that it was indeed kube-scheduler 

I then edited the relevant configuration file: -

/etc/cfc/pods/master.json 

( having backed it up first )

and changed from: -

--tls-cipher-suites=TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_128_GCM_SHA256

to: -

--tls-cipher-suites=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

Once I killed the kube-scheduler process - kill -9 23860 - and waited for kube-scheduler to restart, Nessus was happy.

I also used: -

openssl s_client -connect 127.0.0.1:10259 </dev/null

to validate the cipher being used: -

...

New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES128-GCM-SHA256

...

Job done!

Required reading: -

Modifying Cipher Suites used by Kubernetes in IBM Cloud Private

Sweet32 and Weak Ciphers