Cluster hardening

What it means

Cluster hardening is the work of changing a Kubernetes cluster from its defaults to a setting that follows published good practice. The best known guide is the CIS Kubernetes Benchmark, a long checklist of settings for the control plane, the nodes and the policies that run on them.

A cluster that works is not the same as a cluster that is safe. Out of the box, many clusters favour ease of use, and each convenient default is a place where hardening can narrow what is allowed. Hardening is done one setting at a time on a cluster that already works, and each setting has a clear pass or fail check.

Why it matters

Clusters hold the credentials, the customer data and the deployment rights for a whole product. A weak setting there, such as wide permissions or an open API, can turn one compromised container into control of everything around it. Defaults chosen for convenience stay in place unless someone reviews them.

Benchmarks give you a measurable answer for customers and auditors. Questionnaires often ask whether you follow an accepted standard, and a scored report is easier to show than a statement that the team is careful. The shared responsibility model decides which parts your provider covers and which are yours.

How it shows up

Hardening covers locking down access to the API server, using role-based access control with narrow roles, encrypting secrets, turning on audit logging, applying network policies, and enforcing pod security rules. Tools such as kube-bench run the CIS checks and report what fails.

Common mistakes include hardening once and never again, treating a benchmark pass as proof of safety, and ignoring the workloads. Settings drift as people add things, so repeat the check on a schedule. Managed services handle part of the control plane, so read which items remain yours to set.