Cloud-Native Security Buyer’s Guide

How Kubernetes incidents differ

In a traditional environment, the attacker lands on a host and you image the host. In Kubernetes, the attacker often never needs a host: a stolen service account token, an over-privileged workload identity, or an exposed API server is enough to run workloads you did not ask for, escalate through RBAC, and escape to the node when convenient.

Blast radius works differently too. A compromised cluster-scoped RBAC binding is not one workload; it is everything the scheduler can reach. And the evidence decays faster: pods restart, nodes get replaced by autoscalers, and the node that mattered an hour ago may be gone before anyone looks.

The consequence for buyers: a general DFIR firm without demonstrated cluster fluency will discover all of this during your incident. The directory lists the cloud-native firms whose Kubernetes work is documented, and this guide is how to evaluate anyone else.

What to verify in a firm

Certifications at the holder level. The Kubernetes credentials that matter are CKS (Certified Kubernetes Security Specialist) and CKA, held by named responders. Ask who holds them; issuer registries and program records make the claims checkable.

Managed service experience matching yours. EKS, GKE, and AKS differ enough that a firm fluent in one is not automatically fluent in three, and a self-managed cluster is a fourth world. The RFP captures your distribution and expects firms to answer against it.

Runtime and supply chain fluency. Detection tooling (Falco, Tetragon, Tracee), admission control (Gatekeeper, Kyverno), and supply chain practice (SBOMs, Sigstore signing, SLSA-aligned builds) are the daily vocabulary of a cluster-hardened firm. Firms that have never tuned a Falco rule or verified a Cosign signature will struggle to work your evidence.

What cluster evidence survives

The recoverable set in a cluster incident: the Kubernetes audit logs (the record of what touched the API server), node disk images and memory captures where nodes persist, container images from the incident (the actual artifact, not the registry copy), registry and CI logs for supply chain questions, and the cloud audit logs around the control plane.

What does not survive: pod state after restart, ephemeral container filesystems, and node-local data after autoscaler replacement. That asymmetry is why the first operational question to any firm is: what do you export and preserve in the first hour, before the environment forgets. The forensic evidence article on the blog lists the deliverable set to require in the contract.

What the structured RFP asks

The cloud-native RFP captures the environment precisely: distributions, cluster and node counts, workload profile (multi-tenancy, stateful services, GPU workloads), and the security tooling in place. It asks the attack behaviors you need covered (container escape, RBAC escalation, image supply chain), your log sources and forensic expectations, and verification criteria including CKS holder minimums.

Firms answer in writing against the same questions, and for a market this specialized the answers are diagnostic: a firm that responds with cloud-generic language to Kubernetes-specific questions has answered the only question that matters.