Kubernetes defaults are tuned for developer convenience, not security, which means a freshly stood-up cluster is not production-safe. Hardening it is a finite, well-understood list of controls. Here are the ten we apply to every cluster before it serves real traffic, and they are a concrete expression of zero trust inside the cluster.
1. Role-based access control, scoped tightly
Grant the minimum permissions each user and service account needs. The default of broad access is exactly what an attacker exploits after a single compromise. Deny by default and grant specific roles deliberately.
2. Network policies
By default, every pod can talk to every other pod. Define network policies so components communicate only with what they actually need. This micro-segmentation contains a compromise instead of letting it spread.
3. Drop root and restrict capabilities
Containers should not run as root. Set security contexts to run as a non-root user, drop unnecessary Linux capabilities, and use a read-only root filesystem where possible so a compromised container has little to work with.
4. Pod security standards
Enforce baseline pod security so workloads cannot request dangerous privileges like host access or privileged mode. An admission policy that rejects unsafe pod specs stops the problem before it is deployed.
5. Manage secrets properly
Native secrets are only base64-encoded, not encrypted, by default. Enable encryption at rest, restrict who can read secrets, and consider an external secrets manager. This connects to keeping signing keys and credentials out of your build pipeline.
6. Scan images and use minimal bases
Vulnerabilities enter through container images. Scan every image for known issues, use minimal base images to shrink the attack surface, and rebuild regularly to pick up patches, the same discipline as our Docker production practices.
7. Keep the cluster patched
Old Kubernetes versions carry known, actively exploited vulnerabilities. Stay within a supported version range and enable automated node updates. Treat the cluster version as a security patch, not just a feature upgrade.
8. Limit the API server's exposure
The control plane API is the keys to the kingdom. Do not expose it to the public internet, restrict access by network and identity, and audit who can reach it. A reachable, weakly protected API server is a catastrophic single point of failure.
9. Set resource limits
Without CPU and memory limits, one misbehaving or malicious workload can starve everything else on the node. Limits are both a reliability control and a defence against denial-of-service from within the cluster.
Defence in depth, not a single wall
No single control on this list is sufficient on its own, and that is the point. Security in a cluster works because the controls overlap, so that bypassing one still leaves an attacker facing several more. Tight access control limits what a stolen credential can do; network policies limit where a compromised pod can reach; non-root containers and dropped capabilities limit what an attacker gains from a container escape; and audit logging means that even a successful intrusion is visible rather than silent. Treating any one of these as the answer is the mistake, because a determined attacker will find the gap. The goal is layers, each independently reducing the blast radius, so that the failure of one is contained by the others. Harden the cluster as a system, not as a checklist of isolated boxes to tick.
10. Audit logging and monitoring
Enable audit logs so you can see who did what, and monitor for suspicious activity. Detection is the difference between a contained incident and a breach you learn about from someone else. For the orchestration choice that sits underneath all of this, see our take on Kubernetes versus ECS, and if you want a cluster hardened by specialists, our security team does it.