Security | Threat Detection | Cyberattacks | DevSecOps | Compliance

Kubernetes applications often rely on Persistent Volume Claims (PVCs) to store critical data, from databases to user uploads. Losing this data due to cluster failures or accidents can be catastrophic for DevOps teams. In this post, we’ll walk through how to safeguard your Kubernetes PVCs using CloudCasa, a backup-as-a-service platform.

What is the best eBPF security tool for Kubernetes? For detection-only, Falco. For detection plus enforcement, Tetragon or KubeArmor. For full-stack correlation across cloud, Kubernetes, container, and application layers, ARMO CADR. The right choice depends on whether you need basic visibility, policy enforcement, or complete attack story generation that reduces investigation time by 90%+. Why do most eBPF security tools fail teams? They create more alerts, not better understanding.

Kubernetes networking offers incredible power, but scaling that power often transforms a clean architecture into a tangled web of complexity. Managing traffic flow between hundreds of microservices across dozens of namespaces presents a challenge that touches every layer of the organization, from engineers debugging connections to the architects designing for compliance. The solution to these diverging challenges lies in bringing structure and validation to standard Kubernetes networking.

For years, AI and machine learning workloads lived in the lab. They ran as internal experiments, batch jobs in isolated clusters, or offline data pipelines. Security focused on internal access controls and protecting the data perimeter. That model no longer holds. Today, AI models are increasingly part of production traffic, which is driving new challenges around securing AI workloads in Kubernetes.

Your CNAPP dashboard shows 10,000 critical findings from last night’s scan. Your CSPM flags misconfigurations every hour. Yet when the SOC asks what actually happened during last week’s incident, you’re still stitching together logs from five different tools to build a timeline that makes sense. Sound familiar? We recently spoke with a platform security lead at a fintech company running 400+ microservices on Kubernetes. Their CNAPP generated 47,000 findings in Q3.

What’s the difference between container scanning and container security? Scanning finds vulnerabilities in images before deployment—it’s container auditing, not container security. Real security requires runtime visibility: seeing what processes execute, what network connections occur, and what files get accessed while containers run. Most teams have scanning covered. Most teams are blind at runtime.

Kubernetes workloads comprise more than just container images—they encapsulate state, storage dependencies, service endpoints, and intricate metadata. A naive “lift and shift” approach that moves persistent data, manifest files, and images overlooks the crucial platform-specific configurations required for true application fidelity.

The best security combines configuration controls (TLS, headers, network policies, pod security) with runtime behavioral monitoring that detects anomalies your configuration can’t see. Configuration creates the baseline—it defines what should happen. Runtime protection catches what gets through—it shows what is happening. You need both, but most teams only have the first.

Your ASPM tool flagged 3,400 vulnerabilities across your Kubernetes clusters last night. Your team can remediate maybe 50 this quarter. Which 50 actually matter? Here’s the uncomfortable truth most ASPM vendors won’t tell you: their tools were designed for traditional applications running on traditional servers. They assume your code deploys once and sits there. Kubernetes breaks every one of those assumptions. Pods spin up and die constantly. Deployments change multiple times daily.