☸️ Kubernetes Top 10 Misconfigurations
Intro: Kubernetes misconfigurations matter because the platform is composable. A small default can become a repeated security decision across dozens of namespaces and services.
| # | Misconfiguration | Why it is dangerous | Short fix |
|---|---|---|---|
| 1 | Privileged pods | Removes major isolation boundaries | Deny except for tightly controlled system workloads |
| 2 | Host network / PID / IPC usage | Increases host exposure | Avoid unless there is a compelling platform reason |
| 3 | Containers running as root | Easier privilege abuse | Use non-root and restricted policies |
| 4 | No seccomp / capability hardening | Leaves unnecessary kernel attack surface | Use RuntimeDefault and drop capabilities |
| 5 | No resource limits | Operational instability and denial-of-service risk | Set sane requests and limits |
| 6 | Wide-open NetworkPolicies or none at all | Lateral movement is easier | Start with default deny and explicit allow rules |
| 7 | Excessive RBAC rights | Cluster compromise spreads quickly | Scope roles narrowly and review bindings |
| 8 | Secrets in plain manifests or weak access control | Easy credential exposure | Use secret managers and tighter RBAC |
| 9 | Uncontrolled admission or policy exceptions | Rules become optional | Govern exceptions and phase enforcement carefully |
| 10 | Public dashboards or exposed control components | Direct attack path | Keep management planes private and authenticated |
How to use this page
Use it as a fast triage page during:
- cluster baseline reviews;
- platform enablement workshops;
- post-incident backlog cleanup;
- pre-production design checks for new namespaces or shared clusters.