Examples in this article are illustrative, not customer case studies. Product availability and coverage are described on the linked capability pages.
Ask a platform team which workloads can reach the checkout service’s database and you will usually get a confident answer about one cluster and a shrug about the rest. This post shows how to build Kubernetes security posture management (KSPM) from inventory upwards, so every posture finding describes a cluster you actually run and every gate enforces against it.
KSPM is the continuous assessment of cluster configuration and access state, covering workloads, RBAC, network policy and admission control, against explicit expectations. It starts with a live inventory of every cluster, namespace, workload and service account, because a benchmark only describes the clusters it knows about.
We will follow that checkout service through each layer: what exists, how it connects, who can act on it, and what may change it.
KSPM is continuous because clusters never hold still
The expectations are concrete. No privileged containers without a recorded reason, no service accounts bound to cluster-admin by accident, no namespace without a network policy, and no workload pulling from a registry nobody approved. KSPM is a sibling of cloud security posture management, but the object under management behaves very differently.
A cloud account holds resources with fairly stable identities. A cluster holds workloads that are replaced constantly by reconciliation loops, which will faithfully recreate a misconfigured pod the moment you delete it. The checkout service that passed a benchmark scan at the start of the week may be running a new replica set, a new sidecar and a new service account by the end of it, without anyone acting in bad faith. Posture observed once is a historical record. Posture observed continuously is something you can act on.
KSPM inventory comes before any benchmark
In many organisations running Kubernetes at scale, nobody can produce a complete list of clusters, let alone the namespaces, workloads and service accounts inside them. The platform team governs the production fleet carefully while a data team runs its own cluster with none of the same guardrails. Each cluster has its own API server, RBAC bindings and admission configuration, and nothing forces them to agree.
An inventory worth having records every cluster and its control-plane version, every namespace and the workloads inside it, every service account and the roles bound to it, and the network policies that govern traffic between workloads, including where none exist. For the checkout service, that means knowing not only its own deployment but the namespaces that share its nodes and the batch job in a forgotten cluster that holds a copy of its database credentials. Without that baseline, the question at the top of this post has no reliable answer, and the benchmark results you do have describe only part of the estate.
Topology shows where Kubernetes risk actually travels
Inventory tells you what exists; topology tells you how it connects, and connection is where risk moves. A workload with no vulnerabilities of its own can still be a stepping stone if it sits beside something sensitive under a permissive network policy, or if its service account can do more than its job requires. Mapping which workloads can talk to which, which namespaces share nodes and which service accounts hold which roles turns a flat list into a graph you can query.
For the checkout service, topology is what reveals that a reporting sidecar in a neighbouring namespace can open connections to the checkout database, because that namespace never received a default-deny policy. No single object is wrong on its own; the exposure only appears when the objects are read together.
RBAC sprawl is a posture finding, not a periodic review
Kubernetes RBAC is expressive by design, which is exactly why it sprawls. Every Helm chart brings its own ClusterRoles and bindings, and some operators request broad permissions that need review. Over time a cluster accumulates bindings nobody would approve individually, and the combined effect is that far more service accounts than intended can read secrets, exec into pods or delete resources outside their own namespace.
Treating RBAC as posture means asking continuously which bindings grant cluster-wide power, which service accounts hold permissions they never use, and which roles combine into more privilege than any single binding suggests. For checkout, the sharper question is not whether its own service account is over-privileged but whether any other service account can read the checkout namespace’s secrets. It is the same problem described in excess privilege as graph edges, applied to the Kubernetes control plane.
Admission control is where Kubernetes posture becomes enforcement
Inventory and topology tell you where you stand; admission control decides what may change. It is a policy checkpoint after authentication and authorisation, before an admitted object is persisted. An admission webhook that evaluates policy on every create and update can reject a pod that asks for privileged mode, an image from an unapproved registry, or a role binding that grants cluster-admin without a recorded justification.
A gate that inspects only the object in front of it will approve individually reasonable requests that add up to an unreasonable state. A gate informed by inventory and topology can see that the checkout namespace already hosts a workload with host networking, or that the requesting service account can already read secrets across namespaces, and decide accordingly. The companion post on Kubernetes admission gates and cluster drift covers what to gate on and how to keep the live cluster aligned with what the gate approved.
Cluster posture only makes sense next to image and cloud findings
A workload’s risk depends on the image it runs and the cloud resources it can reach. When KSPM, image scanning and cloud posture live in separate tools, an attack path through all three goes unnoticed while each tool reports its own slice as clean.
The checkout pod traces back to the image digest it runs, the image traces back to the build and commit that produced it, and the pod’s cloud identity shows which storage and databases it can reach. Binding images to workloads makes that trace reliable, and combining posture with workloads turns it into an attack path someone can prioritise.
Key takeaways
- Build a continuously refreshed inventory of every cluster, namespace, workload and service account before running any benchmark.
- Derive topology from network policies, RBAC bindings and workload placement so you can ask what can reach a sensitive workload.
- Review RBAC as a standing posture signal, looking for combined and unused privilege rather than single bad bindings.
- Enforce posture at admission with policy that can see the rest of the cluster, not only the submitted object.
How SecurityVault approaches this
SecurityVault brings collected Kubernetes inventory, configuration and admission context together with image findings. Digest associations help identify which known workloads carry an affected image. Gate policies can use that context where available; required signals and missing-data behavior must be specified in the policy. Runtime execution telemetry from an eBPF sensor remains planned.
Begin with one cluster and compare collected namespaces, workloads and service accounts with an independently obtained inventory. Review a known configuration issue, its owner and the image digest behind the affected workload. Then inspect a collection gap and a policy evaluation that lacks required context. Platform engineers should be able to explain those limits before expanding coverage. The evaluation should establish a repeatable operating process for onboarding, refreshing and reviewing cluster evidence, not simply demonstrate that a dashboard can display Kubernetes objects.
Explore Kubernetes security or talk to our team about an evaluation with your engineering, security and compliance stakeholders.