What a CIS Kubernetes Benchmark Audit Actually Checks

The benchmark starts with the API server, controller manager, and scheduler — checking flags like anonymous-auth, insecure-port, and admission controller configuration. A surprising number of clusters still run with defaults that were reasonable five years ago and are not reasonable now.

etcd holds every Secret in the cluster in near-plaintext unless encryption at rest is explicitly configured. The benchmark checks client certificate authentication, peer authentication, and whether etcd is reachable from outside the control plane network at all. This is one of the highest-severity findings we see in first-time audits.

Kubelet configuration — anonymous authentication, authorization mode, read-only port — gets checked node by node. In managed Kubernetes (EKS/GKE/AKS), much of this is handled by the provider, but self-managed and on-prem clusters (kubeadm, RKE2) carry this risk directly.

This is usually where the real backlog lives. Wildcard RBAC bindings, cluster-admin granted to service accounts that don't need it, namespaces with no NetworkPolicy at all, and pods still running privileged or as root by default. None of this shows up as a red X in most dashboards — it takes a structured review to surface.

A CIS-aligned score is a snapshot, not a certificate. It tells you what fraction of a defined control set you currently satisfy, weighted by severity. The value isn't the number itself — it's the prioritized, severity-ranked backlog that comes with it, because that's what turns “we should look into security at some point” into a scoped, fixed-price engagement.

This is also why we keep Audit and Harden as separate engagements: an audit that also fixes things as it goes can't credibly claim independence, and a hardening engagement without a scored backlog to price against turns into open-ended, unbounded work. Keeping them separate keeps both honest.