Security posture assessment — measuring the cluster

A security posture assessment answers: what is the cluster’s current security state, against a published standard? The answer is a score, a list of findings, and a remediation roadmap. Without a measurement, “secure” is a feeling; with one, it is a number you can track over time. This lesson covers the frameworks, the tools, the cadence, and how to turn the score into action.

Frameworks

A framework is the standard you are measuring against. Without it, the score is meaningless. Three are widely used:

• CIS Kubernetes Benchmark — a vendor-neutral checklist of ~150 controls covering control plane flags, kubelet flags, RBAC defaults, network policies, Pod Security Standards, and workload configuration. Published by the Center for Internet Security, version 1.10+ targets Kubernetes 1.28+.
• NSA/CISA Kubernetes Hardening Guide — a US government publication that covers a similar ground with a focus on federal deployments. Lighter weight than the CIS Benchmark.
• Distribution posture scores — GKE, EKS, AKS each publish their own posture score (GKE Security Posture, EKS Security Best Practices, AKS Secure Score). These are easier to run because they are integrated with the control plane.

flowchart LR
    A[Cluster state] --> B[CIS Benchmark]
    A --> C[NSA Hardening Guide]
    A --> D[Distribution score]
    B --> E[Score + findings]
    C --> E
    D --> E
    E --> F[Roadmap]

Tools

Five tools dominate posture assessment:

Each tool measures a different slice. A defensible posture programme runs them all — kube-bench on the node, kubeaudit on the cluster, polaris on workloads, and kube-hunter from outside the cluster.

Running a posture assessment

# kube-bench on a control-plane node
kube-bench run --targets master,node,etcd --json

# kubeaudit on the cluster
kubeaudit all -f json --cluster default

# polaris on workloads
polaris audit --audit-format json --output polaris-report.json

# kube-hunter from outside (an attacker's view)
kube-hunter --remote target.example.com

# Sample kube-bench output
[INFO] 1 Master Node Security Configuration
[INFO] 1.1 API Server
[WARN] 1.1.12 Ensure that the --profiling argument is set to false (Automated)
[WARN] 1.1.20 Ensure that the --enable-admission-plugins argument is not set to AlwaysAdmit (Automated)
[FAIL] 1.1.22 Ensure that the --service-account-lookup argument is set to true (Automated)
...
== Summary ==
38 checks PASS
12 checks WARN
4 checks FAIL

From score to roadmap

A score is not the deliverable; the roadmap is. The roadmap ranks findings by impact × ease of remediation and produces a backlog of work. The standard ranking:

1. Critical findings — anonymous auth enabled, cluster-admin bound to default SA, etcd without TLS, open kubelet port. Fix within days.
2. High findings — wildcard RBAC, missing audit log, privileged workloads in production. Fix within weeks.
3. Medium findings — defaults that are almost right (e.g., --profiling=true on the API server, which is mostly fine but should be off in production). Fix within the next quarter.
4. Low findings — stylistic choices (e.g., audit log format). Fix opportunistically.

Cadence

The right cadence is continuous, not annual. There are three modes:

• CI/CD gate — every Helm install, every Kubernetes manifest applied via CI runs polaris and kubeaudit. A failing build blocks the deploy.
• Scheduled audit — kube-bench runs as a CronJob weekly; results are exported to the SIEM; a trend chart is reviewed in the security weekly meeting.
• External audit — kube-hunter runs from outside the cluster monthly to validate the network perimeter.

A cluster with no continuous measurement has no posture; it has a snapshot.

Production failure modes

1. Score is reported, not acted on. A security team that runs kube-bench and emails the result without creating tickets in the backlog has a score with no remediation. The score should be the backlog.
2. Score is not tracked over time. A single measurement is a snapshot. The trend (is the score improving?) is the real signal.
3. Score excludes workloads. CIS Benchmark is control-plane heavy. Workload configuration (PSS, limits, probes) is measured by polaris, not by kube-bench. Running only kube-bench misses half the surface.

Cross-course references

• The Observability course covers the SIEM integration that turns posture findings into alerts.
• The Linux course covers the kernel-level checks (sysctl, capabilities) that kube-bench surfaces.

Quiz

Production discipline

A defensible security posture is measured, not asserted. Pick one framework, run it continuously, track the score as a time series, and tie every finding to a backlog ticket with an owner and a due date. The CIS Benchmark is the default; polaris covers the workload side that CIS misses. The score is not the goal — the score trend is the goal. A cluster whose posture score is improving over time is on a defensible trajectory; a cluster whose score is flat or declining is not.