Kubernetes CIS benchmark drift exposes control-plane compliance gaps

At a glance

What this is: This blog post shows how Wazuh SCA can automate CIS Kubernetes Benchmark checks against a kubeadm control-plane node and reveal configuration drift across 77 hardening requirements.

Why it matters: It matters because Kubernetes governance depends on continuous configuration assurance, especially where RBAC, service accounts, pod security, and exposed control-plane settings intersect with identity and privilege.

By the numbers:

• Wazuh's example policy implements 77 requirements from the CIS Kubernetes Benchmark v2.0.1.
• The blog's test cluster surfaced 14 failed checks that required further review and remediation.
• The Wazuh team assessed a kubeadm v1.35.7 control-plane node against the benchmark.

👉 Read Wazuh's blog post on CIS Kubernetes Benchmark assessment with Wazuh SCA

Context

Kubernetes hardening fails most often through configuration drift. As clusters evolve, permissions, authentication settings, admission controls, and pod security settings can move away from the intended baseline even when the platform remains operational. In this post, the primary governance issue is not whether Kubernetes can be secured in theory, but whether teams can continuously prove that control-plane and workload settings still align with the CIS Kubernetes Benchmark.

That question has an identity dimension as well. RBAC, service accounts, certificate handling, and kubelet authentication all shape who and what can act inside the cluster, which makes Kubernetes security a governance problem as much as a platform problem. For teams running human IAM, NHI, or workload identity programmes, the lesson is familiar: if configuration checks are manual, privilege drift becomes visible only after exposure has already widened.

Key questions

Q: What breaks when Kubernetes hardening is only checked at deployment time?

A: Point-in-time checks miss the changes that matter most, such as manual edits, emergency patches, node rebuilds, and authentication flag drift. A cluster can pass on day one and become exposed later without any new build event. Continuous assessment is what turns a baseline into a control, because it catches configuration changes before they widen privilege or exposure.

Q: Why do Kubernetes RBAC and service accounts belong in identity governance?

A: Because they determine which human and non-human principals can act inside the cluster, and under what conditions. RBAC scopes authorization, service accounts represent workload identities, and certificate and token settings define how those identities are trusted. If those controls are weak, cluster access becomes a privilege problem rather than just a platform issue.

Q: What do security teams get wrong about Kubernetes compliance scans?

A: They often treat scans as evidence of a secure cluster rather than evidence of a current posture. A passing result on one node does not prove the whole environment is controlled, especially when different namespaces, admission settings, or kubelet configurations vary. Teams need recurring scans linked to remediation ownership, not isolated audit snapshots.

Q: How should organisations reduce the blast radius of secret exposure in Kubernetes?

A: They should separate credentials by application and environment, constrain service account permissions to the minimum needed, and move production secrets into an external store with audit and rotation controls. The goal is to prevent one workload from becoming a reusable bridge to unrelated systems. That is how teams shrink the blast radius of a compromise.

Technical breakdown

How CIS benchmark checks map to Kubernetes control-plane risk

The CIS Kubernetes Benchmark is a hardening baseline that turns platform configuration into measurable controls. In this blog post, the checks cover API server flags, etcd TLS settings, static pod manifest permissions, controller manager and scheduler bindings, kubelet authentication, RBAC, pod security, and namespace policy. That matters because many Kubernetes failures are not caused by a single exploit. They emerge when insecure defaults, weak file permissions, permissive admission settings, or exposed administrative surfaces accumulate across the control plane and worker nodes.

Practical implication: treat benchmark results as a control-plane risk map, not a one-time compliance report.

How Wazuh SCA evaluates Kubernetes endpoints

Wazuh SCA applies policy logic to monitored endpoints and classifies each check as Passed, Failed, or Not applicable. The policy file uses metadata, requirements, variables, and rule conditions such as all, any, or none, which lets teams target specific files, directories, processes, or command output. In this case, the requirement block checks for the kube-apiserver static pod manifest so the policy only runs where a kubeadm control-plane actually exists. That makes the assessment precise, but it also means policy quality depends on how accurately the checks reflect the cluster build pattern.

Practical implication: align SCA policy scope with your Kubernetes deployment model before relying on the results.

Why RBAC, service accounts, and pod security are identity controls

Kubernetes security is often described as platform hardening, but several of these controls are identity controls in practice. RBAC determines which principals can perform which actions, service account lookup and key handling govern workload authentication, and pod security settings limit how much privilege a container can acquire at runtime. If a cluster allows privileged containers, host namespaces, or broad namespace defaults, the problem is not only workload escape. It is also an access-control failure that expands the blast radius of any compromised identity or pipeline account.

Practical implication: review Kubernetes hardening together with IAM and workload identity governance, not as separate programmes.

Threat narrative

Attacker objective: The attacker aims to turn weak Kubernetes governance into durable cluster control and wider workload access.

1. Entry begins with configuration drift or insecure Kubernetes defaults that leave control-plane files, API server settings, or node services weaker than the CIS baseline expects.
2. Escalation follows when overly permissive RBAC, weak service account handling, or privileged pod settings allow a compromised workload or user to increase access inside the cluster.
3. Impact is broader cluster abuse, including unauthorized administrative actions, lateral movement between namespaces, exposed credentials, or denial of service through overbroad privilege.

NHI Mgmt Group analysis

Configuration drift is the real control-plane threat. Kubernetes hardening rarely fails because a benchmark does not exist. It fails because live clusters drift away from that benchmark as teams patch, upgrade, and reconfigure under delivery pressure. Wazuh's example reinforces a simple governance truth: if you cannot continuously test the baseline, you do not really control the baseline. Practitioners should treat drift detection as an operational control, not an audit afterthought.

Kubernetes security is also identity governance. RBAC, service accounts, certificate files, and API server authentication settings govern how humans and workloads prove who they are and what they may do. That puts Kubernetes squarely in the same governance family as IAM and PAM, even when the control surface looks like platform configuration. The lesson is that cluster hardening should be reviewed alongside workload identity and administrative privilege, not owned as a separate silo.

Continuous compliance beats point-in-time hardening. A benchmark can describe 77 checks, but the security value comes from running those checks repeatedly and tying failures to remediation workflows. This is where SCA becomes useful: it turns a static standard into ongoing evidence. Teams that only validate builds at deployment time will miss later changes introduced by operations, emergency fixes, or manual intervention. Practitioners should operationalize checks as part of the change lifecycle.

Namespace and admission controls define the blast radius. The article's emphasis on pod security, network policies, image provenance, and default-namespace avoidance points to one named concept: cluster privilege sprawl. When admission is permissive and namespaces are shared loosely, one compromised workload can expand into neighboring resources much faster than teams expect. That makes namespace design, pod restrictions, and image controls core containment measures. Practitioners should manage Kubernetes as a privilege-boundary problem, not only a deployment platform.

Automated evidence is now a governance requirement. The practical value of SCA is not just detection, but defensible evidence that security settings still match policy after operational change. That matters for audits, cloud-native resilience, and internal control attestation. Security teams should expect to prove not only that a baseline exists, but that drift is measured and acted on continuously.

What this signals

Kubernetes hardening is increasingly a governance problem, not just an infrastructure problem. As teams adopt more automation around change control and policy assessment, the security bar will shift from static benchmark adoption to evidence that drift is continuously detected and remediated. That is the operational model most aligned with CIS Controls v8 and NIST SP 800-53 Rev 5 Security and Privacy Controls.

Cluster privilege sprawl: when namespaces, RBAC, and admission controls are managed separately, the real risk is not one misconfiguration but the accumulation of small permissions gaps. For identity teams, the signal is clear: Kubernetes is part of workload identity governance, so control ownership must include IAM, platform engineering, and security operations.

Teams that can prove configuration integrity after every meaningful change will be better positioned for audit, resilience, and incident response. The practical next step is to connect benchmark failures to remediation workflows, not to collect them as isolated compliance metrics.

For practitioners

• Automate CIS benchmark checks across cluster lifecycles Run SCA policies after upgrades, node replacements, and manifest changes so control-plane drift is detected before it reaches production workloads.
• Separate Kubernetes identity controls from generic platform checks Map RBAC, service account handling, and certificate settings to your IAM and workload identity governance so access decisions are reviewed with the same rigour as human identities.
• Reduce cluster privilege sprawl at admission time Block privileged containers, host namespace sharing, and unsafe escalation paths before workloads are admitted, especially in namespaces that host mixed-trust applications.
• Treat namespaces as enforcement boundaries Require namespace-specific network policies and avoid the default namespace for production resources so segmentation remains visible and enforceable.

Key takeaways

• Kubernetes hardening fails most often through configuration drift, not the absence of a benchmark.
• RBAC, service accounts, and pod security are identity controls because they govern who and what can act inside the cluster.
• Continuous SCA and namespace-level containment are the controls most likely to reduce blast radius when Kubernetes settings drift.

Key terms

• Configuration Drift: Configuration drift is the gradual divergence between a system's intended secure state and the settings it actually runs with over time. In SaaS, drift often appears when admins change sharing, logging, or access controls under pressure and never return to validate the result.
• Cluster Privilege Sprawl: Cluster privilege sprawl is the accumulation of overly broad permissions, unsafe pod settings, and weak namespace boundaries that expand what one workload or user can reach. It is a containment problem as much as an access-control problem, because it increases blast radius across the cluster.
• Security Configuration Assessment: Security Configuration Assessment is the process of checking systems against defined hardening policies and reporting whether settings match the expected baseline. In practice, it turns configuration standards into repeated evidence, which is essential for cloud-native environments that change frequently.
• Workload Identity: The identity assigned to a software workload — such as a containerised application, serverless function, or microservice — enabling it to authenticate to other services without storing static credentials.

What's in the full article

Wazuh's full blog post covers the operational detail this post intentionally leaves for the source:

• The exact SCA policy structure used to translate CIS Kubernetes Benchmark v2.0.1 checks into YAML rules
• The full list of Kubernetes configuration checks across API server, etcd, kubelet, RBAC, pod security, and namespace policy
• The deployment steps for the Wazuh agent, policy file, and endpoint scanning configuration
• The example dashboard workflow for reviewing failed checks and validating remediation

👉 The full Wazuh post shows how the custom SCA policy maps to Kubernetes control-plane checks and remediation steps.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, secrets management, and identity lifecycle control. It helps practitioners connect Kubernetes access, service accounts, and broader identity governance into one operating model.