Kubernetes hardening: lock down the cluster without breaking what works
A cluster with just the right permissions, a segmented network and images under control, with every change in the repository and applied in phases.
Usual tools
- Kubernetes
- Hetzner
- Vault
- Tailscale
- Helm
- k3s
In short
Hardening a Kubernetes cluster means reducing what an attacker or a mistake can do inside it. We review and lock down RBAC permissions, network policies, pod security standards, image provenance, secrets, API access and audit logging. Every change goes into the repository and is applied in phases, starting in warn mode.
- Languages
- Spanish, Catalan or English
- Response
- The next business day, during business hours
- Method
- In your account and your repository, in code and documented
What is included
- Cluster review against the Kubernetes security recommendations and the CIS Benchmarks.
- RBAC with least privilege per team and per application, with no shared admin accounts.
- Network policies: deny by default and open only what is needed.
- Pod Security Standards per namespace.
- Image control: allowed registries, scanning and pinned versions.
- Secrets encrypted and kept out of the repository.
- Restricted API access and audit logging enabled.
- Everything in code, with a before-and-after report.
Why harden the cluster?
A freshly created cluster works, but it is not designed to limit damage. What we usually find when we review one:
- The whole team logs in with the same cluster admin user.
- Any pod can talk to any other, including the database.
- Some containers run as root or with privileges they do not need.
- Images come from any registry and with the latest tag.
- Secrets sit in the repository in base64, which is not encryption.
- Nobody knows who deleted that deployment on Tuesday because there is no audit log.
Which controls do we apply, and in what order?
Order matters: first whatever reduces the most risk with the least impact on the team’s day-to-day work.
| Control | Risk it covers | How it is applied | Impact on the team |
|---|---|---|---|
| RBAC per team and application | A mistake or a stolen credential with full permissions | Roles per namespace and access with a named identity | Low, each person sees their own resources |
| Audit logging | Not knowing who did what | Enabled and shipped to the central logs | None |
| Network policies | Lateral movement inside the cluster | Deny by default and open per service | Medium, reviewed in warn mode |
| Pod security | Privileged containers or containers running as root | Pod Security Standards per namespace | Medium, some images need adjusting |
| Image control | Images of unknown origin or with flaws | Allowed registries, scanning and pinned versions | Low, if CI already builds the images |
| Secrets | Readable credentials in the repository | Encryption with Sealed Secrets, SOPS or Vault | Low, the process for adding secrets changes |
Access to the cluster API matters too: instead of leaving it open to the internet, we put it behind a private network with NetBird or Tailscale, with named access for each person.
How does the work proceed?
Review
Current state against the security recommendations and the CIS Benchmarks, with the list of findings.
Phased plan
Which control goes first, what it could break and how it is checked.
Warn mode
The policies are deployed without blocking, to see what they would affect.
Enforcement
Whatever is needed gets adjusted and the policies are enforced, phase by phase, from the repository.
Report
The before and after, and anything left pending by your decision.
And after the hardening?
A hardened cluster stops being hardened if nobody keeps an eye on it: new versions, new applications and “temporary” exceptions arrive. If you like, we maintain it as part of SRE as a service, with cluster version upgrades and a review of exceptions in the monthly report. We explain full cluster maintenance in managed Kubernetes, and the Hetzner case, with no managed control plane, in Kubernetes on Hetzner.
What experience do we have?
We work with Kubernetes and Helm on production platforms, with managed providers and on self-managed clusters, with more than ten years of experience in SRE and DevOps. We have also built secure cloud foundations and managed secrets with HashiCorp Vault. Our rule of thumb: security the team does not understand ends up switched off, so every control comes with an explanation.
Frequently asked questions
Will anything break?
The risk is managed by applying changes in phases: first the policies run in warn mode, we review what they would block, adjust them and only then enforce them. Each phase can be rolled back from the repository.
Does it work for a managed cluster such as EKS, GKE or AKS?
Yes. With managed clusters the provider looks after the control plane, but permissions, network, pods, images and secrets are still your responsibility. On k3s or self-managed clusters we also review the nodes and the control plane.
Which tools do you use for policies?
Whatever Kubernetes already provides whenever it is enough, such as Pod Security Admission and NetworkPolicy. If more is needed, Kyverno or OPA Gatekeeper for custom rules. We choose the option with the fewest moving parts that covers what is needed.
Tell us about your case
In a free 20-minute call we look at where you are and where to start. No commitment.
Reviewed on