What is KSPM (Kubernetes Security Posture Management)?
Kubernetes Security Posture Management (KSPM) is the continuous evaluation of Kubernetes clusters against security baselines — RBAC bindings, pod security context, network policy, admission control and secrets handling. It reads cluster state through the Kubernetes API and reports which objects violate policy, why it matters, and how to correct it.
Why Kubernetes needs its own posture management
A cloud posture tool reads the cloud provider's API. It can tell you an EKS cluster exists, which VPC it sits in, and whether its endpoint is public. It cannot tell you that a ServiceAccount inside that cluster is bound to cluster-admin, that a pod runs as UID 0 with the host filesystem mounted, or that no NetworkPolicy exists so every pod can reach every other pod.
Those objects live inside the cluster, behind the Kubernetes API — a different control plane with its own authentication, its own object model and its own failure modes. The cloud provider does not see them, so cloud posture management does not either.
That gap is where KSPM sits. It is not CSPM applied to Kubernetes; it is a separate evaluation against a separate API.
What KSPM actually checks
| Area | Typical findings |
|---|---|
| RBAC | ClusterRoleBindings granting cluster-admin, wildcard verbs, service accounts with escalate or bind |
| Workload context | Privileged containers, hostPID and hostNetwork, root UID, writable root filesystem, missing seccomp |
| Network | No default-deny NetworkPolicy, services exposed via LoadBalancer without restriction |
| Secrets | Secrets mounted as environment variables, unencrypted etcd, tokens auto-mounted where unused |
| Admission and supply chain | No admission control, unsigned images, images from untrusted registries, :latest tags |
| Control plane | Anonymous auth enabled, insecure kubelet ports, audit logging off |
The CIS Kubernetes Benchmark is the usual baseline, and most of these map to it directly.
KSPM vs container scanning vs CWPP
These three get used interchangeably and are not the same thing.
- Container image scanning looks at the image: which packages it contains and which have known CVEs. It answers is this artefact vulnerable?
- KSPM looks at the cluster: how workloads are configured, who can do what, what can talk to what. It answers is this cluster configured safely?
- CWPP looks at the running workload: process behaviour, file integrity, runtime detection. It answers is something happening right now?
A vulnerable image (scanning) running as root (KSPM) that starts a reverse shell (CWPP) is one incident described by three tools. Treating any one of them as the whole picture is the common mistake.
Why RBAC is the part that matters most
Image CVEs get the attention because there is a number attached to them. But the finding that most often converts a container compromise into a cluster compromise is an over-permissive ServiceAccount.
The chain is short and well-worn: a pod is compromised through the application, its ServiceAccount token is auto-mounted at a known path, that token is bound to a role with broad verbs, and the attacker now speaks to the API server with those permissions. Nothing in that sequence requires a CVE.
This is why KSPM findings should be read as a graph rather than a list. Which subjects can reach which resources, and what does that let them do next? is a more useful question than how many High findings do we have?
Where KSPM fits with cloud posture
A Kubernetes cluster is not an island. It runs on cloud infrastructure, its nodes have instance roles, and its workloads assume cloud identities through mechanisms like IRSA or Workload Identity.
The interesting failures cross that boundary in both directions: a pod that assumes a node role which can read a production bucket; a cloud IAM policy that grants access to the cluster's control plane. Evaluating cluster posture and cloud posture separately produces two correct reports that both miss the path between them.
Getting started
- Connect the cluster read-only — a kubeconfig or service account with
get,listandwatch. No agent is required for posture evaluation. - Baseline against CIS Kubernetes first. It is well understood, it is what auditors ask about, and it produces a finite list.
- Fix RBAC before image CVEs. It is less satisfying and it removes more real risk.
- Add a default-deny NetworkPolicy. Most clusters have none, and it is the single change that most reduces lateral movement.
- Re-evaluate continuously. Clusters change hourly; a quarterly audit describes a cluster that no longer exists.
Frequently asked questions
Is KSPM different from CSPM?
Yes. CSPM reads the cloud provider's API and sees the cluster as one resource. KSPM reads the Kubernetes API and sees the objects inside it — RBAC bindings, pod security context, network policy, admission control. A cluster can be perfectly configured at the cloud layer and unsafe inside.
Does KSPM require an agent in the cluster?
Posture evaluation does not. Cluster state is readable through the Kubernetes API with a read-only credential. Runtime detection — process behaviour, file integrity, syscall monitoring — is a different capability and does typically need something running in the cluster.
What baseline should KSPM measure against?
The CIS Kubernetes Benchmark is the standard starting point and the one auditors recognise. Pod Security Standards, NSA/CISA Kubernetes hardening guidance and NIST SP 800-190 are common additions once the CIS baseline is clean.
Which KSPM finding should be fixed first?
Usually an RBAC one. Over-permissive ServiceAccounts and ClusterRoleBindings are what turn a single compromised pod into cluster-wide access, and unlike image CVEs they cannot be resolved by a rebuild.