How Kubernetes Vulnerabilities Have Shifted Since the First API Attacks
Kubernetes has many built-in security features but that doesn’t mean it’s secure right out of the box. Security for dependency management is still lacking and new attack vectors, such as malicious containers, are emerging. Despite advances in security, the API remains Kubernetes’ main entry point for attackers.
The good news is that security teams have learned a lot about how to protect Kubernetes deployments and applications running on containers over the past few years. Such threats can be more easily addressed through a combination of workflows and tooling that span developers, security teams and IT operations (“DevSecOps”). For example, malicious containers and other attack vectors are easy to spot through anomaly detection and scanning tools.
In this edition of The New Stack Makers podcast, Robert Haynes, cloud security evangelist for Palo Alto Networks, discusses Kubernetes security above and beyond the native features, as well as the evolution of the Kubernetes vulnerability landscape since the first API attacks took place a few years ago. Alex Williams, founder and publisher of The New Stack, hosted this episode.
Kubernetes Has Evolved, So Should Your Security
Kubernetes security — and its limitations — are also themes covered in The New Stack’s “The State of the Kubernetes Ecosystem” ebook, which Palo Alto Networks supported as a sponsor. One of the main security issues addressed in the book is how Kubernetes is not built to offer any and every security feature an organization might need. However, the good news is that security teams have been able to glean a lot about how to protect deployments and applications running on containers and Kubernetes over the past few years.
“If you assess Kubernetes, how it works, and what it’s designed for, the two or three key ways that people are going to try and abuse it are fairly obvious,” said Haynes. “And I think that was reflected as we saw the early critical CVEs come in.”
Since the first API attacks, the security community has done a reasonably good job of assessing how attacks have been orchestrated. The first critical attacks a couple of years ago against an API service “taught us something we already knew…that Kubernetes is software and all software has vulnerabilities,” said Haynes.
“The thing I think we can take away from the early things was actually quite encouraging. So, yes, there was a problem, and it was an open source project that lots of people were using that had a critical security vulnerability — what was the response going to be like?” Haynes explained. “And actually, the response was pretty good. I think the kind of maintainers of Kubernetes can be fairly satisfied they did a decent job of finding, fixing and then communicating that problem out there.”
Despite advances in security, the API remains Kubernetes’ main entry point for attackers. “The API server is a critical and obvious part of the infrastructure that’s potentially open to attack. Kubernetes was built so the developers could run things sort of quickly. And on a platform, they didn’t have to worry about the underlying architecture. So that kind of implies that people have to better get access to…tell it to do stuff,” said Haynes. “So there’s no way of getting away from not having a fairly comprehensive control plane, and therefore, that’s always going to be a point you need to critically protect.”
