CNAPPs were designed with very little focus on Kubernetes security in the first place. CNAPPs began to bundle different cloud security tools, which were rushed and missed some needs peculiar to Kubernetes. 

The emergence of Kubernetes scanning tools like kube-bench and Kubescape underscores the dynamic nature of the field of Kubernetes security, although these tools are still very far from delivering a universal security solution. This presents a challenge to CSPMs and the agents adding partial Kubernetes support, with their primary focus remaining on configuring the cloud in general. Kubernetes-specific vulnerabilities and runtime protection remain underserved by traditional CNAPPs. 

Many of the existing CNAPPs do not have much depth in Kubernetes security features such as admissions controllers and runtime context awareness.  CNAPP with its gap in Kubernetes security provides a feel-good factor, a false sense of security. We will see how AccuKnox CNAPP deals with this Kubernetes Gap in this blog.

Why CNAPP ≠ CSPM + CWPP?

First is the duct tape approach, general CSPM scanning, and vulnerability scanning. Neither of these features alone will help in defending a Kubernetes cluster. That is much more important to secure Kubernetes compared to just searching for CVEs in images, and a cursory glance at the cloud provider’s APIs doesn’t scan the Kubernetes control plane.

These signals from CSPM scanning come in highly relevant shapes and sizes, whereas Kubernetes is more of an afterthought due to cluster data being just more painful to get than cloud data. While “agentless scanners” could easily query cloud APIs for things like EBS volumes or EC2 instances, they often lack the integrations to query the control plane itself of Kubernetes to learn about actual cluster operations. This may be the number one reason that “agentless” is out of favor. “Agentless” has come to mean, “You don’t see inside the cluster very well.”

The vulnerability scanning feature in containers has become further and further commodified; at the same time, it is rather irksome. Security teams have been starting to give up, content to use the open-source Trivy as a checkbox for scanning. Indeed, without runtime context (CWPP), vulnerabilities just may not mean anything. Scanners often miss critical issues, making genuine positives surprising compared to false ones. Vulnerabilities in images are only relevant when considered alongside the specific packages in use and their operating environments. The true value of CVEs emerges from insights provided by Kubernetes.

Scenarios

Let’s look at five examples of how current CNAPP offerings fall short.

Scenario	CNAPP Security Challenge	Impact
Misconfiguration in RBAC Policy	Misses unauthorized access in Kubernetes due to RBAC misconfiguration.	Privileged pods created, data exfiltration.
Lack of Runtime Context	Finds many vulnerabilities and lacks threat prioritization.	Resources wasted on low-risk issues are critically ignored.
Ineffective Network Policy Guidance	Detects suspicious pod traffic but lacks network policy guidance.	Lateral movement within compromised pods.
Insecure Environment Variables	Misses insecure environment variable configs and detects only hard coded secrets.	Sensitive data is exposed via environment variables.
Container Escape & Lateral Movement	Spots container escape but misses lateral movement.	The attacker accesses resources across namespaces.

Scenario 1: Poor Control Plane Visibility

A CNAPP solution governs an extended cloud ecosystem. In this highly complex Kubernetes environment, the solution is brilliant at managing a range of aspects but fails within a Kubernetes cluster because of misconfiguration in the RBAC policy. Due to misconfiguration, it allows an attacker to have unauthorized access, resulting in spawning privileged pods. After elevation, such privileged pods start exfiltrating sensitive data and compromise the security posture of the organization. This negligence to the detection capabilities of the CNAPP makes the security team dependent on manual audits for the detection of the breach. What this turns the focus to is how CNAPP solutions should develop their mechanisms of real-time detection for threats that are Kubernetes-specific, ensuring a proactive rather than reactive security posture.

Scenario 2: Insufficiency of Runtime Context of Vulnerabilities

A company deploys CNAPPs within its Kubernetes clusters and finds thousands of vulnerabilities across the environment. It’s difficult to know what the minor problems are versus the critical vulnerabilities sans runtime context. The security team could be swamped by the size of these alerts and is treating minor patches at the expense of key vulnerabilities. This scenario gives a lesson on why CNAPP solutions need runtime context to enable security teams to laser-focus efforts on significant threats and drive effective resource allocation.

Scenario 3: Enforcement of a Poorly Written Network Policy

CNAPP generates alerts related to the suspicious pod-to-pod or intra-pod traffic in a Kubernetes cluster, but it fails to give any actionable guidance related to a network policy that can be used to contain such threats. Without such details, the information on pod compromise will remain connected, and lateral movement across the cluster is possible. The security team is still devoid of the tools needed for the isolation of the threat, and an increased breach occurs. This therefore calls for the need for CNAPPs—not just to detect threats but also to provide complete context-aware guidance to proactively mitigate these risks at speed and scale.

Scenario 4: Poor Secrets Management

A CNAPP identifies hard-coded secrets within Kubernetes deployments but misses the insecure environment variables containing sensitive information within the pods. This oversight exposes the data for exposure in case some threat actor gains access to these compromised pods. This incident reveals a critical oversight in CNAPP’s monitoring and protection capability concerning environment variables, hence underlining the importance of comprehensive security coverage entailing all facets of Kubernetes deployments.

Scenario 5: Partial runtime detection

An attempted container escape inside a CNAPP-controlled environment will raise an alert. The solution, however, remains blind to the further movement of the attacker inside the Kubernetes cluster. The attacker makes use of filched service account tokens to move across sensitive resources in a differently namespaced setting. This proves that CNAPP is blind in terms of identifying and responding to sophisticated attack patterns, placing a demand on the solution to improve its lateral movement detection and response capabilities.

Closing the Gap with a Combined Approach

This represents how organizations will necessarily need to take a significantly more holistic approach to the security of their Kubernetes:

• Running Kubernetes-native security solutions that enable deep visibility into the control plane and workloads
• Running context-aware vulnerability management that can take account of runtime information to make a proper risk assessment
• Auto-generating and enforcing network policy, custom-made for a Kubernetes-centric environment.
• Use a secrets manager solution that integrates in Kubernetes natively.

Implement advanced runtime security solutions capable of early detection and response to recent, more sophisticated types of attacks across the entire Kubernetes ecosystem.

By combining these strategies as part of the existing functionalities of CNAPP, an enterprise would be substantially raising its Kubernetes security posture. More significant still, the security of Kubernetes deployments deserves special treatment, one that is noticeably distinct from traditional cloud security practices.

Learn more about Kubernetes security best practices using the materials below.

1. Kubernetes Security Cheat Sheet from OWASP
2. CIS Kubernetes Benchmark
3. NIST Application Container Security Guide