Palo Alto Networks Digs Into Kubernetes Security Flaw
The Unit 42 research arm of Palo Alto Networks this week issued a security alert that warns a previously disclosed Kubernetes vulnerability may be more severe than initially appreciated.
An issue known as CVE-2020-8558 was recently discovered in the kube-proxy, a networking component of a Kubernetes node. Internal services of Kubernetes nodes often run without authentication when set at default. It turns out that on certain versions of Kubernetes, this vulnerability can expose the Kubernetes api-server, which could allow an unauthenticated attacker to gain complete control over the cluster.
The core CVE-2020-8558 issue is localhost services, which are meant to be accessible only from the node itself, become exposed to hosts on the local network and to pods running on the node.
Jen Miller-Osborn, deputy director for threat intelligence for Unit 42, says localhost bound services expect that only trusted, local processes can interact with them so they are often not configured without any authentication requirements.
While a patch has been released to address the CVE-2020-8558 issue, Miller-Osborn says some older versions of Kubernetes don’t disable the api-server insecure-port, which is normally only accessible from within the master node.
The ultimate fix adds mitigations around route_localnet: routing rules that cause nodes to drop external packets. Route_localnet is still enabled by the kube-proxy, but Miller-Osborn says there are ongoing discussions about disabling it. Even with those mitigations applied, there’s still a unique scenario in which cyberattacks could send packets to Kubernetes internal UDP services. However, the attack only works if the victim node disables reverse path filtering.
Miller-Osborn says cybersecurity concerns are not likely to hold back further adoption of Kubernetes, but they will encourage IT teams to make sure they have a Kubernetes update strategy in place. Many early adopters of Kubernetes are still running older, less secure versions of the platform because they are concerned about updates breaking their applications. Many of the application programming interfaces (APIs) employed in those older versions have been superseded in the latest versions of Kubernetes.
Organizations that have embraced Kubernetes should, by necessity, be embracing best DevSecOps practices to ensure the security of both the cluster and the cloud-native applications deployed on those clusters.
In the meantime, the debate over container security rages on. On the one hand, cloud-native applications based on containers should be more secure because it’s much easier to rip and replace containers that have vulnerabilities in comparison to patching monolithic applications. Yet, applications built using containers are based on microservices that have a lot of dependencies; if a vulnerability goes undiscovered for a significant period of time, the potential damage inflicted could be considerable.
Of course, developers are embracing containers as a way to build and deploy applications that are more resilient and flexible. If over time those applications prove to be more secure, developers may see that as an added bonus that cybersecurity teams will one day fully appreciate.