Safeguard
Application Security•

What is Kubernetes security posture management (KSPM)?

KSPM checks Kubernetes clusters against security baselines to find misconfigurations. What to check per the Kubernetes checklist and NSA guide.

Safeguard Security Team
4 min read

Kubernetes security posture management (KSPM) is the continuous practice of checking cluster configuration against a security baseline and fixing drift. It looks for risky settings such as over-broad permissions, open network paths and weak pod settings. You can do it with a checklist and a script before you buy a product.

Why does Kubernetes need posture checks?

Kubernetes is a large system with many settings, and the defaults suit getting started, not locking things down. The Kubernetes documentation's security checklist says plainly that security is not one size fits all, and each category of checklist items should be evaluated on its merits. It is described as a baseline.

Clusters also change constantly. A manifest edited on Friday can open a path that was closed on Thursday. Posture management exists because a one-time review goes stale.

The NSA and CISA published a joint Kubernetes Hardening Guide in August 2021 and updated it in 2022. It provides recommended configuration and hardening guidance for setting up and securing a cluster. Together with the official checklist, it gives a free starting baseline.

What does the checklist cover?

The Kubernetes checklist groups items into areas: authentication and authorization, network security, pod security, logs and auditing, pod placement, secrets, images and admission controllers. Some sample items from the authentication area: the system:masters group is not used for user or component authentication after bootstrapping, the root certificate is protected, and intermediate and leaf certificates expire no more than three years out.

In plain words, here is what a posture check looks for:

  • Permissions. Who can do what through role bindings? Is anyone a cluster administrator who does not need to be?
  • Network. Are there network policies, or can every pod talk to every other pod?
  • Pod settings. Do containers run as root, in privileged mode or with host paths mounted?
  • Secrets. Are they stored and encrypted properly, and who can read them?
  • Images. Do workloads pull from approved registries, and are images scanned?
  • Admission control. Are there rules that reject risky workloads before they start?
  • Logging. Is the audit log on, and does it go somewhere safe?

What does a finding look like?

A constructed example: a team runs one cluster for several apps. A posture check lists three results. First, a debugging service account has cluster-wide admin rights, left from an old incident. Second, no network policy exists in the namespace that holds a payments service, so any pod can connect to it. Third, one deployment runs privileged because someone copied a sample manifest.

None is dramatic alone. Together they mean a flaw in any one pod could reach the payments service and then the whole node. The fixes are small: remove the binding, add a default-deny policy and drop the privilege. The value of KSPM is that it found them before an attacker did.

KSPM or something else?

KSPM looks at configuration. It does not see everything. It will not tell you whether an image contains a vulnerable library, whether a workload is behaving oddly at runtime, or whether a developer's laptop is compromised. Pair it with image and dependency scanning and with runtime monitoring.

How to check or apply this

  1. Take the Kubernetes security checklist and mark each item as met, not met or not applicable for your cluster.
  2. List every cluster role binding that grants administrator rights and justify or remove each.
  3. Add a default-deny network policy to each namespace, then allow only the traffic you need.
  4. Enforce pod security rules so privileged and root containers are rejected by default.
  5. Scan the images you deploy and limit registries to approved ones.
  6. Run the check on a schedule and when manifests change. Alert on new failures.
  7. Compare against the NSA and CISA hardening guide for items the checklist misses, and record exceptions with owners.

Quick check

Is KSPM the same as image scanning?

No. KSPM checks cluster and workload configuration. Image scanning checks the contents of container images for known vulnerabilities. You need both.

Do I need a product to start?

No. The official Kubernetes checklist and the NSA and CISA hardening guide give you a baseline to check by hand or script. Products help with scale and drift.

Sources

Last reviewed: 18 October 2026.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.