The Kubernetes Gap in CNAPP
Exploring why many CNAPPs have a Kubernetes gap
We’ll return to the runtime series next week! This week we’ll be looking at why most CNAPPs have a gap with Kubernetes protection, and maturity differs so widely between providers.
CSPMs and CNAPP have a major gap, and unfortunately, it drives the majority of your cloud that actually matters (Kubernetes). To be frank, most CNAPPs were created around two things:
Acquiring and merging otherwise unrelated “cloud security tools”
Supporting enterprise cloud adopters before they had fully adopted cloud native architectures
Even the early players in the space who recognized the value of containerization found themselves too ahead of the market to support the giant funding opportunities present from their competition, who were focused on easily scanning every cloud workload that could exist. This led to:
CSPMs adding half-baked agents
Agents adding half-baked CSPMs
Most recently, EDRs adding “cloud scanning”
The Development of Kubernetes Scanning
One small example of this shift was my comparison of kube-bench and Kubescape. When I was getting started in cloud security, kube-bench was the gold standard I was taught for scanning Kubernetes because it scanned for CIS benchmarks. But over time, it’s apparent that providers like ARMO who have stayed dedicated to Kubernetes protection have continued to evolve their scanner, while others have had to stretch themselves thin across a million different cloud configurations. I don’t mean this to be a giant “shots fired” or anything - I still think Aqua is great, and they are still better than most CNAPPs at Kubernetes protection, they’re just focusing on a wide variety of different things. Now I find running a Kubescape scan to be the best way to get started for security teams learning Kubernetes.
Even the extremely basic scanning of kube-bench is far ahead of what many CNAPPs offer when it comes to Kubernetes. First, the average CNAPP consists of general CSPM scanning, duct taped together with some kind of container vulnerability scanning. Neither of these functionalities provide much value to actually protecting Kubernetes clusters. Securing Kubernetes is much more than the CVEs on the images, and the Kubernetes control plane isn’t scanned very deeply by just checking the cloud provider’s API’s.
With CSPM scanning, these alerts vary wildly in their usefulness, and Kubernetes is the after thought because cluster data is so much harder to get than cloud data more broadly. While “agentless scanners” can easily interrogate cloud API’s for things like EBS volumes or EC2 instances, they often don’t have the integrations necessary to interrogate the Kubernetes control plane to get an idea of what’s actually running in the cluster. This is a key reason why not many people market as “agentless” anymore, I’ve come to think of “agentless” as “you don’t see inside the cluster very well.”
With container vulnerability scanning, this feature has become increasingly commoditized and frustrating at the same time. Many teams I know have given up and now resort to just scanning with the open source Trivy as a checkbox. Indeed, vulnerabilities with no runtime context can be totally meaningless - I myself have been desensitized to these endless scanners. I’m much more shocked to see a true positive than a false one. Image vulnerabilities only matter in two contexts: what packages are running, and where are they running. Only Kubernetes insights can drive value from CVEs.
What are some things that are missed?
Beyond CVEs, Kubernetes scanning has a lot of depth that’s missed by traditional CNAPP providers. This image shows the suite of Kubernetes functionalities that have security applications, and they’re color coded by how common it is to find detections in CNAPP for those. Green means most CNAPPs support them. Yellow tend to be supported by the more Kubernetes focused CNAPPs. Red means I can’t recall seeing them supported by a CNAPP provider.
Unfortunately, many CNAPP providers treat each of these as simple yes/no checkboxes, building things like admissions controllers only for the purposes of vulnerability management (which no one actually enforces). Instead, admissions controllers can be used to enforce all sorts of helpful OPA policies, runtime policies, disabling privilege escalations, and more. Many security tools built their Kubernetes support at one point in time, and have failed to adapt to the newer features and creative approaches for applying Kubernetes security.
The worst part of CNAPP’s Kubernetes immaturity is it gives security teams a false sense of security about the state of their cloud infrastructure. You can have all green with just a few Kubernetes checkboxes, but in reality be building a giant mess inside the cluster that goes undetected.
Some other simple examples of a lack of maturity are:
Tools that show network traffic, but don’t tell you if a network security policy is active or help you build one
Tools that offer runtime protection, but don’t build sec comp profiles to help enforce security
Tools that offer table views of SA accounts and RBAC, but don’t actually help you understand what certain roles have access to.
Tools that check for hard coded secrets in Kubernetes files, but have no broader context of how secrets are getting delivered to your running pods.
Tools that continue to struggle to categorize if a finding is on a node, pod, or container, or have blind spots with cronjobs or sidecars.
From a runtime protection perspective, many CNAPP’s Kubernetes runtime detections have been okay at detecting some simple alerts, most commonly container escapes because they’re easy to detect. However, I once assessed a provider who appeared to only have a “new namespace created” alert. While modern CNAPP detection content has surpassed legacy EDR tools like CrowdStrike and SentinelOne, they have lagged behind innovators who have focused on this area. More specifically, they often don’t provide context to their alerts - opting instead to have a very container isolated view of the runtime event.
What I mean by “Container Isolated” is that they can see things like one process starting another, they often miss any pivoting between containers or attacks that interact with the control plane. For example, there’s one alert from a CNAPP that is decently mature in this area that comes to mind where it would trigger whenever “kubectl” was run from within a pod. While that’s an okay start, it would totally miss any direct interaction with the kubeapi that wasn’t done with kubectl - the tools are taking shortcuts to say they have functionalities they don’t really offer.
In conclusion, CNAPPs lack Kubernetes viability in three areas: the nature of their CSPM detections, the depth of in-cluster understanding, and the rapidly evolving nature of runtime detection in Kubernetes. While some CNAPPs are more advanced than others in these areas, overall their lack of focus on Kubernetes specifically has created a sizeable gap in this area compared to “cloud detection” more broadly.
To find Kubernetes focused providers, you can check them out on the Latio List.
This post was done in collaboration with ARMO.