What is KSPM (Kubernetes Security Posture Management)?

KSPM at a glance

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.

How KSPM works

1. Connect. A read-only identity in the cluster — typically a ServiceAccount whose role allows get, list and watch on the objects being assessed.
2. Inventory. Enumerate namespaces, workloads (Deployments, DaemonSets, StatefulSets, Jobs, Pods), RBAC objects, Services and Ingresses, NetworkPolicies and admission webhooks.
3. Evaluate. Test every object against a baseline — CIS, Pod Security Standards, or your own policy.
4. Prioritise. Rank findings by context: is the workload exposed, what can its ServiceAccount reach, does it run privileged?
5. Remediate. Fix the manifest or Helm chart at source, not the live object, or the next deploy reverts the fix.
6. Prevent and repeat. Add admission policy so the same violation cannot be deployed again, and re-evaluate continuously — clusters change with every deploy.

KSPM checklist: what KSPM checks

KSPM vs CSPM

Managed Kubernetes settings straddle both. The CIS EKS, AKS and GKE benchmarks exist for exactly that reason: they cover the cloud-side cluster settings and the in-cluster policies together, and drop the control-plane checks the provider now owns. You need both views — a cluster can be perfectly configured at the cloud layer and unsafe inside. See What is CSPM? for the cloud side.

KSPM vs CWPP vs container image scanning

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: vulnerabilities inside it, process behaviour, runtime detection. It answers is this workload exploitable, and 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.

CIS Kubernetes Benchmark, NSA/CISA hardening and Pod Security Standards

CIS Kubernetes Benchmark. Published by the Center for Internet Security, it is the baseline auditors recognise. Its recommendations are grouped into control-plane components, etcd, control-plane configuration, worker nodes, and policies (RBAC, Pod Security, network policy, Secrets). For managed services, use the CIS EKS, AKS or GKE benchmark instead — the provider runs the control plane, so those versions keep the checks you can still act on.

NSA/CISA Kubernetes Hardening Guidance. Published jointly by the US National Security Agency and the Cybersecurity and Infrastructure Security Agency. Its themes map cleanly onto KSPM: scan containers and pods for vulnerabilities and misconfiguration, run them with least privilege, separate networks with network policy, use strong authentication and authorisation, enable audit logging, and review configuration regularly.

Pod Security Standards. Kubernetes' own three-level policy — Privileged, Baseline and Restricted — enforced by the built-in Pod Security Admission controller through namespace labels. Most clusters should aim for Baseline everywhere and Restricted for application namespaces.

NIST SP 800-190 (Application Container Security Guide) is a common addition for regulated environments once the CIS baseline is clean.

Admission control: from finding problems to preventing them

KSPM reports what is already running. Admission control decides what is allowed to run. A mature programme uses both: KSPM finds the existing violations, and admission policy stops new ones from being deployed.

• Pod Security Admission — built in, enforces the Pod Security Standards per namespace, with enforce, audit and warn modes.
• ValidatingAdmissionPolicy — built-in policies written in CEL, without running a webhook.
• Policy engines — Kyverno and OPA Gatekeeper, for policies the built-ins cannot express, such as allowed registries or required labels.

Roll new policies out in audit or warn first, fix what they report, then switch to enforce. A good KSPM check is simply: does this cluster have admission control at all, and is it enforcing or only auditing?

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? Kubernetes RBAC is an entitlement problem — the same question CIEM answers for cloud IAM.

KSPM examples: three findings and their fixes

1. The default ServiceAccount is bound to cluster-admin. Every pod in the namespace that does not name a ServiceAccount inherits full control of the cluster. Fix: bind a namespaced Role with only the verbs the workload uses, and stop mounting the token where it is not needed.

apiVersion: v1
kind: ServiceAccount
metadata:
  name: default
  namespace: payments
automountServiceAccountToken: false

2. A pod runs privileged with the host filesystem mounted. A container escape becomes a node compromise. Fix: drop privilege in the security context and enforce the Restricted Pod Security Standard on the namespace.

securityContext:
  runAsNonRoot: true
  allowPrivilegeEscalation: false
  readOnlyRootFilesystem: true
  capabilities:
    drop: ["ALL"]
  seccompProfile:
    type: RuntimeDefault

3. A namespace has no NetworkPolicy. Every pod can reach every other pod in the cluster. Fix: apply a default-deny policy, then allow only the flows the application needs.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny
  namespace: payments
spec:
  podSelector: {}
  policyTypes: ["Ingress", "Egress"]

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, EKS Pod Identity or GKE 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. That is the argument for running KSPM inside a CNAPP rather than as a separate tool, and for attack path analysis across both layers.

KSPM best practices

1. Connect read-only. Posture assessment needs get, list and watch, not write access.
2. Baseline against CIS first. It is well understood, it is what auditors ask about, and it produces a finite list. Use the managed-service variant for EKS, AKS and GKE.
3. Fix RBAC before image CVEs. It is less satisfying and it removes more real risk.
4. Add a default-deny NetworkPolicy. Many clusters have none, and it is the single change that most reduces lateral movement.
5. Fix at source. Change the manifest, Helm chart or Kustomize overlay; patching the live object is undone by the next deploy.
6. Turn findings into admission policy. Every class of finding you fix twice should become a rule that blocks it.
7. Re-evaluate continuously. Clusters change with every deploy; a quarterly audit describes a cluster that no longer exists.

KSPM tools

Open-source tools cover parts of the job well: kube-bench runs the CIS Kubernetes Benchmark checks on nodes, Kubescape (a CNCF project) scans clusters and manifests against CIS and NSA/CISA controls, and Polaris checks workload configuration best practices. Kyverno and OPA Gatekeeper handle the admission side.

Commercial KSPM is usually delivered as part of a CNAPP. When you compare options, ask: does it cover your managed and self-managed distributions, does it show RBAC as reachable paths rather than a list, does it connect a pod's identity to the cloud permissions it can assume, and does it re-evaluate continuously?

How Onam approaches Kubernetes posture

Onam treats Kubernetes as one of the seven environments its posture engine covers, alongside AWS, Azure, GCP, OCI, Alibaba Cloud and IBM Cloud. 824 of its 9,853 CSPM posture rules are Kubernetes rules, evaluated with the same finding format as the cloud rules, so a cluster finding and the cloud finding it connects to are read in one place. One honest limit: posture rules evaluate configuration — they do not, on their own, detect an attack in progress inside a pod.

• Onam Container & Kubernetes Security
• Onam on Kubernetes