The runaway success of Kubernetes adoption by enterprise software developers has created motivation for attackers to target these installations with specifically designed exploits that leverage its popularity. Attackers have become better at hiding their malware, avoiding the almost trivial security controls, and using common techniques such as privilege escalation and lateral network movement to spread their exploits across enterprise networks. While methods for enforcing Kubernetes security best practices exist, they aren’t universally well known and require specialized knowledge, tools, and tactics that are very different from securing ordinary cloud and virtual machine use cases.

The evidence of increasing Kubernetes-focused attacks comes from direct telemetry, reinforced by anecdotal reports. Security vendors such as Palo Alto Networks, Wiz, and Aqua Security all have put in place Kubernetes honeypots that see rapid attempts at compromising new clusters, with a newly created cluster being attacked within minutes or a few hours. These attacks scan well-known TCP/IP ports 10250-9 used by containers to communicate with each other, for example. These pre-attack scans happen dozens of times daily, an indication of automated and programmatic efforts to compromise the underlying code.

Let’s examine the threat landscape, what exploits security vendors are detecting, and ways that enterprises can better harden their Kubernetes installations and defend themselves.

Kubernetes threat landscape

A report from the Cloud Native Computing Foundation illustrates the complexity of the landscape, with an interlocking collection of data flows, dependencies, and processes. These components require their own protective methods to encrypt communications, authenticate containers, storage repositories and users appropriately, and protect containers from being exploited. The diagram below (from the Foundation, interpreted by Trend Micro) shows that there is a steep learning curve to understand all the relationships and how the various parts fit together.

The complexity of this architecture was done deliberately, because Kubernetes “was designed to allow users to have a lot of freedom and used an open architecture and a default security model of being open by default,” Assaf Morag, a data analyst with Aqua Security, tells CSO. But despair not: “The fact that Kubernetes is such a sprawling platform with so many integrations presents an opportunity. It makes it easy to build an automated, systematic set of processes that bakes security into the core of the Kubernetes build and deployment process,” as Palo Alto Networks’ recent “Complete Guide to Kubernetes Security” mentions in its introduction. However, the inherent openness of Kubernetes means that there is no single security toolset that does everything. 

Going back to security basics

Often, basic network security postures such as not exposing secret encryption keys, using complex and non-default administrative passwords, deploying various segmentation schemes and following least privilege access rights are seemingly forgotten when it comes to how containers are secured. “We have reverted back to the threats we saw across our 1990s networks,” Palo Alto Networks manager of cloud threat intelligence Nathaniel Quist tells CSO.