Kubernetes security: where to start
Kubernetes gives huge flexibility and an equally large attack surface. We cover the most common mistakes — RBAC, secrets, networking — and hardening priorities.
Kubernetes has become the default way to run applications in the cloud and on your own infrastructure. It gives flexibility, but also a large, complex attack surface: a cluster is networking, identities, secrets and images all in one. In tests we most often see the same mistakes — and that’s where hardening should start.
The most common misconfigurations
- Overly broad RBAC. Service accounts and users with
cluster-admin“to make it work” mean that compromising one pod grants control over the cluster. It’s the same sin of excessive privileges as in the cloud. - No network policies. By default, every pod can talk to every other. Without a
NetworkPolicy, a compromised container moves freely across the cluster. - Secrets in plaintext. Passwords and tokens in environment variables, manifests or a git repository instead of a secrets manager.
- Over-privileged pods. Containers run as root, with
privileged, host access or the Docker socket — a ready-made container escape route. - Exposed dashboard and API. A publicly accessible API server or dashboard without strong authentication.
Hardening priorities
- Restrict RBAC to least privilege — separate service accounts per app, no
cluster-admin“just in case”. - Deploy network policies with default-deny and explicitly allowed traffic between services.
- Enforce Pod Security Standards — no root, no privileged mode, only the necessary capabilities.
- Manage secrets outside manifests (an external manager, encryption in etcd).
- Secure your images — vulnerability scanning, trusted registries, signatures; this is part of the supply chain.
Don’t forget monitoring
Hardening isn’t everything — you also need visibility. Enable the API server audit log, collect logs and alert on suspicious actions (creating high-privilege accounts, launching privileged pods, unusual exec into containers). A good reference is the CIS Kubernetes Benchmark, but — as with Linux hardening — apply it with understanding, not blindly.
If you’d like to check how resilient your cluster is and how far an attacker could get after compromising a single pod, book a test.
Sources and further reading: CIS Kubernetes Benchmark, Kubernetes — Security.