During regular security audits, we are being flagged for weak ciphers being used on several Kubernetes v1.15 clusters. These vulnerabilities are being spit out by Kubernetes itself residing on:
tcp: 6443,10250,443 - SSL Medium Strength Cipher Suites Supported
With that being said, I have scoured the internet and cannot find a straight awnser on how to implement strong ciphers. I tried adding the different flags:
I have always hated audits like that; those that use words like 'Medium' instead of giving you quantified data. Before any configuration changes, I'd recommend getting a baseline of what ciphers you're actually supporting. There are lots of scripts out there, but here's what I use.
You could add another loop if you're actually supporting anything but TLS1.2. Once you have a quantified list of your supported ciphers, you can re-run it to test changes on your CLI. Let me know if this helps.
#!/usr/bin/env bash
# OpenSSL requires the port number.
SERVER=<VIP IP>:443
DELAY=1
ciphers=$(openssl ciphers 'ALL:eNULL' | sed -e 's/:/ /g')
echo Obtaining cipher list from $(openssl version).
for cipher in ${ciphers[@]}
do
echo -n Testing $cipher...
result=$(echo -n | openssl s_client -cipher "$cipher" -connect $SERVER 2>&1)
if [[ "$result" =~ ":error:" ]] ; then
error=$(echo -n $result | cut -d':' -f6)
echo NO \($error\)
else
if [[ "$result" =~ "Cipher is ${cipher}" || "$result" =~ "Cipher
:" ]] ; then
echo YES
else
echo UNKNOWN RESPONSE
echo $result
fi
fi
sleep $DELAY
done
I think you need to be careful about what "regular security audits" are telling you, especially from automated processes and scans.
In general (but not always) a "weak cipher" means a "fast cipher" because the "weaker the cipher" the faster the processing.
In other words, you cannot just say "a cipher is weak, we must change it to strong" for many reasons:
Weaker ciphers are faster to process.
Based on your risk model, faster processing maybe better than slower processing.
This means you need to ask yourself:
What are the ciphers used for and what is the risk model?
If the ciphers for Kubernetes are only used for command and control the weak ciphers may be perfectly okay and the best option.
Think of it like this:
If you have a top secret document you need to protect for 100 years, then you need a cipher which can withstand a brute force attack raged over many years, because the requirement is for a very cryptographically strong cipher which can withstand years and years of computer processing brute-force attacks.
If you are protecting transient data which has a short lifespan security requirement, like command and control information, a weak cipher may be your best option because speed of processing (and length of the cipher-text) is critical and you do not need to protect that information beyond the lifecycle of the session.
In other words, just because an automated system scan says "this cipher is weak", that information has no meaning without putting the information in context with the security requirements and lifecycle of the information being encrypted.
Thank you both. Those are excellent points. The problem is that the security audits fall under the Federal FISMA and PCI compliance. So any attestation of compliance will not be issued unless I can find out how to implement this correctly. Some will be applied before a cluster is built and some that are live in production.
This is the "laymen's view" of Federal guidelines, in my view.
FWIW, I worked for a decade (or so) as a leading unix/linux/networking consultant to the US government, including the USAF, DOD, DISA, and the US Department of Energy" and during that time I encountered countless ill-conceived or misguided bureaucratic rules and guidelines and in almost every case, I made my case and I received a waiver or permission to proceed when I provided the justification.
In your post @metallica1973, you have not offered any professional security analysis for this cipher requirement nor how it impacts the mission / task. We can either (1) let automated scanning tools be our boss, or (2) we can be the boss (the engineers) and we let the automated processing be "only tools" we use. In my prior professional career in this area, I have always worked as (2), not (1).
So far, in this post, I have not read the basic information on what, exactly the cipher is used for in the Kubernetes lifecycle, nor the risk management analysis of that part of the lifecycle, including the perceived vulnerability, threat and criticality of the application.
In my limited experience with Kubernetes, encryption is used for command and control (C2) data between the hosts, and for this application "weak ciphers" should be "just fine" because there is no reason for these ciphers to be "strong" (computational intensive); but then again, that depends on a properly conducted risk management assessment, and not an automated scanning tool or overly simple process.
Anyway, that's just me... because I have always been "the most senior guy" in the room, and have "knocked down" more ill-conceived US government policies and regulations than I can count!