Skip to content
ELI5: Kubernetes se...
 
Notifications
Clear all

ELI5: Kubernetes security - do I need a separate tool or is my CNAPP enough?

2 Posts
2 Users
0 Reactions
0 Views
(@grafana_knight_shift)
Estimable Member
Joined: 4 months ago
Posts: 92
Topic starter   [#10772]

Alright, let's set the scene: I'm a few hours into my shift, my Grafana dashboards are stable, and I'm staring at our k8s clusters. We've onboarded a Cloud-Native Application Protection Platform (CNAPP) for its CSPM and IaC scanning. It flags a workload with `privileged: true` and I get an alert. Good.

But then I start thinking about runtime. That same CNAPP *can* do some k8s workload protection (CWPP stuff), like detecting shell commands in containers. But is it... deep enough? I've always approached this like monitoring: you need the right tool for the layer.

So my core question: For those running k8s in production, do you find your CNAPP's k8s security coverage sufficient, or do you layer on a dedicated k8s security tool (e.g., something open-source like Falco, or a commercial k8s-specific product)?

Where I see potential gaps:
* **Admission Control:** CNAPP often gives you a policy engine, but is it as integrated/real-time as a dedicated Kubernetes Admission Controller (e.g., OPA Gatekeeper, Kyverno) for *preventing* misconfigurations at deploy?
* **Network Policy Visualization & Enforcement:** Understanding pod-to-pod traffic flows within the cluster. Many CNAPPs see cloud network flows, but the intra-cluster east-west stuff feels different.
* **Runtime specifics:** Detecting `kubectl exec` into a pod, suspicious role binding changes, or anomalous API server calls. Does your CNAPP ingest Kubernetes audit logs as effectively as a tool built for it?

Example: A CNAPP might see a weird outbound call from a VM. A k8s tool might see that the same call originated from a pod that was just deployed via a compromised service account.

I'm leaning towards "both" – the CNAPP for the unified cloud security posture, and a k8s-native tool for the granular, in-cluster runtime context. But I hate tool sprawl. What's your real-world experience?

- away



   
Quote
(@ci_cd_plumber)
Reputable Member
Joined: 3 months ago
Posts: 156
 

You're right to be skeptical about the runtime coverage. CNAPPs are often checking a compliance checklist, not monitoring the cluster's actual behavior.

Your point on admission control is the key one. A CNAPP policy engine usually scans what's already deployed. Gatekeeper or Kyverno stops the bad deployment before it hits the API server. That's a fundamental layer of protection you can't get from a periodic scan.

For network policy, most CNAPPs will show you a scary diagram of "all traffic allowed," but they rarely help you build the actual NetworkPolicy YAML to fix it. You need a dedicated tool for that insight.

We run both. The CNAPP gives the security team their checkbox for audits. The dedicated k8s security tools (we use Falco and Gatekeeper) are what actually prevent and catch runtime issues. The CNAPP's alerts are usually too late.


Build once, deploy everywhere


   
ReplyQuote