Recently, an issue that was named CVE-2020-8558 was discovered in a networking component of a Kubernetes node known as the Kube-proxy. In the last week of July 2020, the research arm of Palo Alto Networks, Unit 42, issued a security alert that warns of the same vulnerability.
The warning was that it could be more severe than what initial reports indicated. When on default settings, the internal services on Kubernetes nodes run without authentication.
On some versions of Kubernetes, the vulnerability can expose the API-server, which would allow an attacker to have complete control over the entire cluster.
Patches and fixes
The issue is a localhost service, which generally can be accessed from the node. If it becomes exposed to the local network and pods running the node, it poses a severe problem. Unit 42’s deputy director, Jen Miller-Osborn, says that the local host-bound services are configured to expect only trusted local processes and do not have any authentication requirements.
A patch has been released to deal with the issue of CVE-2020-8558. Even with that in place, Jen says that previous versions of Kubernetes do not disable the API-server insecure port, which should typically only be accessible from the master node.
DevSecOps is the best option for now
The best fix would be to engage routing rules that make nodes drop external packets, or they could disable this feature. Even with that, there are some concerns about unique scenarios where attacks are possible.
It is time for organizations adopting Kubernetes to make use of DevSecOps techniques in safeguarding clusters and cloud-native apps deployed on the clusters. As the debate over container security continues, some facts remain the same.
Containers are flexible in building and deploying applications that are resilient and flexible. If they are more secure as time goes by, it could be a bonus for cybersecurity.
1 day ago
