A cloud posture tool can report a managed Kubernetes cluster as fully compliant while every pod inside it runs privileged, every namespace token can read secrets and anyone with a developer role can create a cluster-admin binding. Cloud security posture management (CSPM) reads the cloud provider's control plane: accounts, networks, storage, IAM and the managed cluster resource itself. Kubernetes security posture management (KSPM) reads the Kubernetes API: RBAC, admission policy, workload specifications, node and control plane settings. This guide compares the two by the layers each sees, how they treat RBAC, admission control and workload identity, where the tools overlap, and how to decide what to run. It is for cloud security leads, platform engineers and buyers running managed or self-hosted Kubernetes on one or more clouds. For CSPM operations in depth, see the Cloud Security Posture Management (CSPM) Guide; for the open source cluster scanners, see the kube-bench and Kubescape Guide.
Key takeaways
- The short answer is around the cluster versus inside it. CSPM checks the cloud resources that host and surround the cluster; KSPM checks the Kubernetes objects and settings that decide what runs and who can change it.
- The seam is the managed cluster resource. Endpoint exposure, control plane logging, node pool settings and encryption options are cloud API settings that CSPM sees; RBAC bindings, Pod Security Admission labels and service accounts are Kubernetes objects that only a tool with cluster API access sees.
- Workload identity spans both and is where escalation hides. A Kubernetes service account mapped to a cloud role is half in each tool's view, so neither will flag an over-permissioned pod-to-cloud path unless the two inventories are joined.
- Prevention lives in admission, not in the scanner. KSPM findings only stop recurring when the same rules run as Pod Security Admission, ValidatingAdmissionPolicy or a policy engine at the API server.
- Buy one inventory, not two dashboards. Most CNAPP suites now offer both; the test is whether a single finding can show the cloud role, the service account and the workload together.
The short answer
If your Kubernetes estate is small and fully managed, CSPM with its managed-cluster checks covers the cloud half and a free cluster scanner covers the rest. Once you run more than a handful of clusters, allow teams to deploy their own workloads or map pods to cloud roles, you need KSPM as a continuous capability, because the highest-impact Kubernetes misconfigurations are objects inside the API that change daily: role bindings, namespace labels, privileged pod specs and service account tokens. CSPM does not read those objects. Platforms are described here by category only; no product is recommended.
The layers each one sees
| Layer | Example settings | CSPM | KSPM |
|---|---|---|---|
| Cloud account and organisation | Guardrail policies, audit trail enabled, root or owner MFA | Primary | Not in scope |
| Network around the cluster | VPC, subnets, security groups, load balancer exposure | Primary | Partial: sees Services of type LoadBalancer and Ingress objects |
| Managed cluster resource | Public or private API endpoint, authorised networks, control plane logging, secrets encryption with a cloud key, version and support status | Primary through cloud APIs | Partial: CIS checks for the managed variant where the provider exposes them |
| Node pools and node images | Node OS image, instance metadata settings, node IAM role, auto upgrade | Primary | Partial: kubelet configuration and file permissions on self-managed nodes |
| Control plane components | API server flags, etcd encryption, admission plugins (self-managed clusters) | Not visible | Primary on self-managed clusters; provider-owned on managed ones |
| Kubernetes RBAC | ClusterRoleBindings, wildcard rules, escalate, bind, impersonate verbs | Not visible | Primary |
| Admission and policy | Pod Security Admission labels, ValidatingAdmissionPolicy, webhooks | Not visible | Primary |
| Workload specifications | privileged, hostPath, hostNetwork, capabilities, runAsNonRoot, seccompProfile | Not visible | Primary |
| Workload identity | Service account to cloud role mapping, token automount | Cloud role side only | Service account side only |
| Network inside the cluster | NetworkPolicy coverage, default deny per namespace | Not visible | Primary |
The pattern is that CSPM owns everything a cloud API returns and KSPM owns everything the Kubernetes API returns. The managed cluster sits on the boundary, and the Center for Internet Security (CIS) reflects that with separate benchmarks for upstream Kubernetes and for each managed service: as listed on its site in November 2026, Amazon EKS, Azure AKS, Google GKE, Oracle OKE and Red Hat OpenShift each have their own benchmark, alongside EKS Auto Mode, AKS Automatic and GKE Autopilot variants. Managed variants drop most control plane checks because the provider operates those components. See the CIS Benchmarks Guide.
Threat model: what each defends against
ATT&CK references below are from ATT&CK v20.
| Threat | CSPM view | KSPM view |
|---|---|---|
| Internet-exposed API server reached with stolen credentials, then T1613 Container and Resource Discovery | Primary: flags a public endpoint with no authorised network ranges | Partial: flags anonymous auth or broad bindings to system:authenticated |
| Attacker deploys a privileged pod, T1610 Deploy Container, then T1611 Escape to Host | Not visible | Primary: namespaces without enforce labels, existing privileged or hostPath pods |
| Persistence through a new binding, T1098.006 Additional Container Cluster Roles | Not visible | Primary: who holds bind, escalate or RBAC write rights |
| Command execution through the API or kubelet, T1609 Container Administration Command | Not visible | Primary: pods/exec and nodes/proxy grants |
| Secrets harvested through the API, T1552.007 Container API | Partial: secrets encryption setting on the managed cluster | Primary: list and watch on secrets, token automount |
| Pod credentials used against cloud storage, T1078.004 Cloud Accounts then T1530 Data from Cloud Storage | Primary on the role: wildcard or broad storage permissions | Primary on the mapping: which service accounts and pods can assume it |
| Backdoored image, T1525 Implant Internal Image | Partial: registry exposure and encryption | Partial: image source and tag policies at admission |
The pod-to-cloud row is the one that matters most in practice. The 2019 Capital One breach was not a Kubernetes incident, but it shows the shape: a workload's cloud role had far more storage access than its job needed, and once the workload was reached the role did the rest. In a cluster the same path runs through a service account mapping, and it is invisible unless the role and the mapping are evaluated together. Runtime attacks such as a live escape attempt are a detection problem for workload protection, covered in CWPP vs CSPM.
Architecture in words
CSPM
A CSPM service holds a read-only role in each cloud account, or one organisation-level role, enumerates resources through provider APIs and evaluates them against rules. For Kubernetes it reads the managed cluster resource (for example the EKS cluster, AKS managed cluster or GKE cluster object), its node groups and the IAM roles attached to nodes and workloads. It does not need, and usually does not have, a Kubernetes credential, so it never calls the Kubernetes API.
KSPM
A KSPM capability needs an identity inside each cluster. It is deployed in one of three ways: an in-cluster agent or operator with a read-only ClusterRole that lists RBAC objects, namespaces, workloads and policies; an agentless connector that the platform uses to call the API server with a mapped identity; or a job that runs node-level checks against kubelet configuration and file permissions on self-managed nodes. Open source examples show the split: kube-bench runs the checks documented in the CIS Kubernetes Benchmark, and Kubescape, a CNCF incubating project, scans clusters, YAML files and Helm charts against NSA-CISA, MITRE ATT&CK and CIS frameworks. Mature KSPM also scans manifests in pipelines, so the same rule applies before deployment, at admission and in the running cluster.
The read access itself is a risk
A KSPM reader that can list secrets is a credential store in waiting. The Kubernetes RBAC good practices page warns that list or watch on secrets returns their contents, and that get on nodes/proxy is not a read-only permission because it reaches the kubelet API. Scope the scanner's ClusterRole to exclude secret contents and the nodes/proxy subresource, and treat the platform holding it as a privileged system. See Securing the CNAPP and CSPM platform itself.
RBAC and admission control: KSPM territory
Kubernetes RBAC and admission control are the two places where cluster posture is actually decided, and both are Kubernetes objects. The Kubernetes documentation lists specific privilege escalation risks that a KSPM rule set should check as a minimum:
- Listing secrets: list or watch on secrets in a namespace exposes every secret value in it.
- Workload creation: anyone who can create pods, Deployments or Jobs in a namespace can run them as any service account in that namespace and so inherits that account's rights.
- escalate, bind and impersonate: each bypasses the normal rule that you cannot grant rights you do not hold.
- nodes/proxy: grants access to the kubelet API, including command execution, outside audit logging and admission control.
- CSR approval and token requests: approving certificate signing requests or holding create on serviceaccounts/token can mint credentials for powerful identities.
- Admission webhook configuration: write access to webhook configurations lets a subject read or alter objects admitted to the cluster.
For admission, the PodSecurity admission controller enforces the Pod Security Standards through namespace labels in three modes: enforce rejects violating pods, audit records them in the audit log and warn returns a warning to the user. The Baseline profile blocks known privilege escalations such as privileged containers, host namespaces and hostPath volumes; Restricted adds requirements such as runAsNonRoot, dropping ALL capabilities, a RuntimeDefault or Localhost seccomp profile and allowPrivilegeEscalation set to false. PodSecurity and ValidatingAdmissionPolicy are both in the default enabled admission plugin list in current Kubernetes releases, so the KSPM question is not whether the controller exists but which namespaces carry which labels. Details are in the Kubernetes RBAC Guide and the Kubernetes Admission Control Guide.
CSPM's contribution here is narrow but real: it can confirm the managed cluster uses cloud identity for authentication, that legacy static credentials are off where the provider exposes that setting, and that control plane audit logs are exported, which every RBAC investigation later depends on.
Workload identity: the shared seam
All three major managed services now federate a Kubernetes service account to a cloud identity, and each splits the configuration across both APIs. Providers are listed alphabetically.
| Platform | Mechanism (per vendor docs) | Cloud side (CSPM sees) | Cluster side (KSPM sees) |
|---|---|---|---|
| Amazon EKS | EKS Pod Identity: an agent DaemonSet on each node issues credentials; an association maps a service account in a namespace to an IAM role. IRSA, the older method, uses an OIDC identity provider. | IAM role, its permissions and a trust policy naming the pods.eks.amazonaws.com service principal; the association in EKS | The service account, which pods use it and who can create pods in that namespace |
| Azure AKS | Microsoft Entra Workload ID: the cluster's OIDC issuer signs a projected service account token; a federated identity credential on a managed identity or app registration trusts it; pods opt in with the azure.workload.identity/use label. | Managed identity, its role assignments and federated credentials | The service account annotation azure.workload.identity/client-id and labelled pods |
| Google GKE | Workload Identity Federation for GKE: a fixed pool named PROJECT_ID.svc.id.goog; the GKE metadata server exchanges a service account token for a short-lived federated token. | IAM bindings to principal or principalSet identifiers for a namespace or service account | The namespace and service account names that match those identifiers |
Two vendor-documented details show why the join matters. Google notes that workloads in different clusters sharing a pool with the same namespace and service account name are treated as the same identity, so a binding written for one cluster may grant another. AWS notes that an association maps one role per service account, so anyone who can create pods using that service account obtains the role. In both cases the cloud permission looks scoped in CSPM and the service account looks harmless in KSPM; the risk is only visible as a path. See the Kubernetes Workload Identity Checklist and Kubernetes RBAC vs Cloud IAM.
Failure modes
- CSPM only, cluster assumed covered: the cluster resource is green while privileged pods, wildcard roles and default service account tokens go unseen. This is the most common gap in estates that adopted CSPM first.
- KSPM only, cloud blind: the cluster scores well but the node IAM role can read every bucket, the API endpoint is public and control plane logs are off.
- Scanner findings with no admission control: the same privileged pod finding reappears after every deployment because nothing rejects it at the API server.
- Benchmark mismatch: running the upstream CIS Kubernetes checks against a managed cluster produces control plane failures the customer cannot fix, which trains teams to ignore the report.
- Over-privileged scanner: the KSPM agent's ClusterRole includes secrets or broad wildcards, turning the security tool into the best lateral movement target in the cluster.
- Unjoined identity: two tools each report the service account and the cloud role as low risk because neither evaluates the mapping between them.
Decision criteria
| Your situation | Lean towards | Why |
|---|---|---|
| Few managed clusters, one platform team deploys everything | CSPM plus periodic open source cluster scans | Change rate inside the cluster is low and the team controls admission |
| Many clusters, product teams deploy their own workloads | Continuous KSPM with admission enforcement | RBAC and workload specs drift daily; prevention must sit at the API server |
| Self-managed or on-premises Kubernetes | KSPM with node and control plane checks | No provider owns the control plane, so API server and etcd settings are yours |
| Heavy use of pod-to-cloud identity | One platform that joins both inventories | The escalation path crosses the boundary between the tools |
| Regulated workloads needing benchmark evidence | Both, mapped to the managed CIS variant | Auditors expect evidence for the cloud account and the cluster |
Small organisations: start with native CSPM from your provider, turn on Pod Security Admission in warn and audit mode on every namespace, and run a cluster scanner weekly. Large organisations: require that the posture platform show cloud role, service account, namespace and workload in one finding, and that its rules run in CI, at admission and at runtime. If you are also weighing code-to-cloud tooling, see ASPM vs CNAPP.
Worked scenario
A retailer runs twelve GKE clusters. CSPM shows every cluster green: private endpoints, control plane logging on, secrets encrypted with a customer-managed key. A KSPM pilot on three clusters finds that the payments namespace has no Pod Security labels, a CI service account holds create on pods cluster-wide, and a reporting workload's service account is bound to a Google Cloud role with storage read across the project. CSPM had flagged that role months earlier as broad, but the ticket was closed as "used by an internal job". Joining the inventories shows the actual path: anyone who can push a pipeline change can run a pod as the reporting service account and read every bucket. The fix sequence is to label the namespace Restricted in audit then enforce, replace the CI cluster-wide pod rights with namespaced roles, narrow the IAM binding to the one bucket, add a condition limiting it to the reporting cluster, and add an admission rule rejecting new pods that use the reporting service account outside its own Deployment.
How to implement both
- Inventory clusters from the cloud side: use CSPM to list every managed cluster, endpoint exposure, version, logging and node role. Unknown clusters found here are the first KSPM targets.
- Pick the right benchmark per cluster: map each cluster to the CIS variant for its service and mode, and suppress control plane checks the provider owns, with the reason recorded.
- Deploy KSPM read access with a reviewed ClusterRole: exclude secret contents and nodes/proxy; store the platform's credentials as privileged.
- Baseline RBAC and workloads: list cluster-admin bindings, wildcard rules, escalation verbs and privileged pods. Fix the highest-impact bindings first.
- Turn on admission in audit and warn: label namespaces with Baseline enforce and Restricted audit and warn, read the audit results for two release cycles, then raise enforcement namespace by namespace. Roll back by relabelling the namespace, which takes effect for new pods immediately.
- Join workload identity: export service account to cloud role mappings and evaluate each role's permissions; flag any role reachable by a service account in a namespace where many subjects can create pods.
- Shift left: run the same rules against manifests and Helm charts in CI so developers see the finding before admission does.
Detection and measurement
Posture tells you what could happen; audit logs tell you what did. Export cloud control plane logs and Kubernetes audit logs to the same detection platform, and alert on new ClusterRoleBindings, pods created with privileged or hostPath, exec into pods in production namespaces, and service account tokens requested by unexpected subjects. See the Kubernetes Audit Log Detection Guide.
- Cluster coverage: percentage of clusters found by CSPM that also report to KSPM. Target 100%.
- Admission enforcement: percentage of non-system namespaces with a Pod Security enforce label of Baseline or Restricted.
- Privileged surface: count of subjects holding cluster-admin, escalate, bind, impersonate or nodes/proxy, trended monthly.
- Identity paths: number of service account to cloud role mappings where the role has wildcard actions or project-wide data access.
- Recurrence: share of KSPM findings that reappear within 30 days of closure, a direct measure of missing admission rules.
Framework mapping
| Framework | Reference | CSPM contribution | KSPM contribution |
|---|---|---|---|
| NIST CSF 2.0 | PR.PS-01 Configuration management practices | Cloud and managed cluster settings | Cluster, RBAC and workload settings |
| NIST CSF 2.0 | PR.AA-05 Access permissions managed with least privilege | Cloud roles used by nodes and workloads | RBAC bindings and service accounts |
| NIST SP 800-53 Rev 5 | CM-6 Configuration Settings, CM-7 Least Functionality | Benchmark conformance per account | Benchmark and Pod Security conformance per cluster |
| NIST SP 800-53 Rev 5 | AC-6 Least Privilege | IAM role scope | RBAC rule scope and escalation verbs |
| CIS Controls v8.1 | Control 4 Secure Configuration of Enterprise Assets and Software | Cloud resources | Clusters and workloads |
| NIST SP 800-190 | Application Container Security Guide | Host and registry context | Orchestrator and container guidance |
Common failure patterns
- Treating a managed cluster as a single cloud resource: the provider secures the control plane, but RBAC, admission labels and workloads are customer-side settings.
- Enforcing Restricted everywhere on day one: breaks system and legacy workloads and leads to blanket exemptions; use audit and warn first.
- Leaving the default service account in use: the Kubernetes good practices page recommends avoiding automatic token mounting where workloads do not call the API.
- Closing broad cloud role findings as "internal use": internal workloads are exactly what an attacker reaches after the first foothold.
- Two tools, two owners, no shared ticket: cloud governance and platform teams each fix their half while the path between them stays open.
Practitioner checklist
- Every managed cluster in CSPM inventory also reports to a KSPM capability.
- Each cluster is assessed against the CIS benchmark variant for its service and mode.
- API endpoints are private or limited to authorised networks, and control plane audit logs are exported.
- Non-system namespaces carry a Pod Security enforce label, with Restricted in audit and warn.
- Subjects with escalate, bind, impersonate, nodes/proxy or RBAC write rights are listed and reviewed quarterly.
- Service account token automount is off where workloads do not call the Kubernetes API.
- Every service account to cloud role mapping is reviewed with the role's permissions in the same view.
- The KSPM scanner's own ClusterRole excludes secret contents and nodes/proxy.
- Posture rules run in CI against manifests and Helm charts as well as against live clusters.
Standards and references
- Kubernetes: Role Based Access Control Good Practices
- Kubernetes: Pod Security Standards
- Kubernetes: Admission Control in Kubernetes
- CIS: Kubernetes Benchmarks
- NIST: SP 800-190 Application Container Security Guide
- AWS: Learn how EKS Pod Identity grants pods access to AWS services
- Microsoft Learn: Use Microsoft Entra Workload ID with AKS
- Google Cloud: About Workload Identity Federation for GKE
Related NHI Mgmt Group resources: CNAPP Guide, Kubernetes Security Checklist, Kubernetes Service Account Token Guide, Container Security Guide.