Kubernetes Security in 2025: What the CIS Benchmark Doesn't Tell You

CIS Kubernetes Benchmark v1.9 is a solid starting point. Organizations that pass it have done real work. But in every Kubernetes cluster assessment we run, we find critical issues that no benchmark checks for.

The Benchmark Coverage Gap

The CIS benchmark is a static checklist. It evaluates configuration state — pod security standards, API server flags, etcd encryption at rest. It cannot evaluate:

• Runtime behavior — What actually runs in your cluster at 2am
• RBAC blast radius — What an attacker can do with any given service account token
• Network policy coverage — Which pods can actually reach which services (vs. what your policies say)
• Supply chain exposure — Where your container images come from and what's in them

RBAC: The Real Attack Surface

In cluster assessments, RBAC misconfiguration is the most common critical finding. The pattern we see repeatedly:

# "Read-only" service account that isn't
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: monitoring-viewer
subjects:
- kind: ServiceAccount
  name: prometheus
  namespace: monitoring
roleRef:
  kind: ClusterRole
  name: view  # Sounds safe...

The view ClusterRole includes secrets read access in many cluster configurations. Prometheus scrapes every namespace. That service account token, if exfiltrated, can read secrets cluster-wide.

What we do instead:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: prometheus-scrape
  namespace: monitoring
rules:
- apiGroups: [""]
  resources: ["pods", "endpoints", "services"]
  verbs: ["get", "list", "watch"]
# No secrets. No ClusterRole. Namespace-scoped.

Network Policy Enumeration

Most teams deploy network policies. Few validate them. Our assessment includes:

# Enumerate actual reachability from a compromised pod
kubectl run -it attacker --image=nicolaka/netshoot --rm -- \
  bash -c "nmap -sT -p 80,443,5432,6379 10.0.0.0/16 2>/dev/null | grep -i open"

We regularly find database ports reachable from frontend pods despite network policies claiming otherwise — usually due to policy gaps on namespace selectors.

Container Image Supply Chain

# What's actually running in your cluster?
kubectl get pods -A -o jsonpath='{range .items[*]}{.spec.containers[*].image}{"\n"}{end}' \
  | sort -u | head -30

In a recent assessment:

• 3 images pulled from Docker Hub (not a private registry)
• 1 image last rebuilt 847 days ago — 31 known CVEs, 4 critical
• 2 images running as root with privileged: true

None of this fails a CIS Benchmark check.

What a Real Cluster Assessment Looks Like

Our Kubernetes security engagement covers:

1. CIS Benchmark baseline — The table stakes
2. RBAC graph analysis — Every service account, role binding, and escalation path
3. Network reachability testing — Actual traffic validation, not policy review
4. Workload security — Pod security context, privileged containers, host mounts
5. Secrets management — Encryption at rest, secret access patterns, external secrets usage
6. Supply chain — Image provenance, vulnerability scanning, base image age
7. Runtime behavior — eBPF-based syscall profiling for behavioral anomalies

Conclusion

Pass the benchmark. Then call us to find what it missed.

Your Kubernetes security posture is only as strong as what you've actually tested under adversarial conditions.