Kubernetes security: where to start

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.

Cluster responsibility boundaries

Kubernetes security spans the control plane, nodes, workloads, images, identities and cloud dependencies. A managed service may maintain the control plane, while the organisation still owns RBAC, workloads, secrets, networking and integration configuration. Document that split for every cluster.

Use separate short-lived identities for people, CI/CD and workloads. Avoid system:masters after bootstrap. Each ServiceAccount needs task-specific rights, and automatic token mounting should be disabled where a pod does not need it.

Pod Security Standards and admission

The Restricted profile constrains privileged execution, host namespaces, dangerous capabilities and root. The standard document does not enforce itself: use Pod Security Admission or another policy controller. Begin with audit and warning, reduce exceptions, then move to enforcement.

Every exception needs an owner, namespace scope and expiry. Otherwise a “temporary” privileged pod becomes a permanent node-compromise path.

Secrets, etcd and network traffic

Kubernetes Secrets are not a vault by default. Restrict read RBAC, enable encryption at rest for etcd, protect backups and consider an external secret manager. Never place secrets in images, ConfigMaps or logs.

NetworkPolicy works only with a supporting network plugin, so verify behaviour. Start with default-deny ingress and egress, then allow minimum DNS, application dependencies and observability flows. Monitor connection attempts so policy is more than a repository file.

Evidence of a healthy cluster

Combine configuration with tests: who can create pods, who can exec, whether a pod reaches metadata APIs, whether tokens mount and whether network policy truly blocks traffic. Repeat regression tests after Kubernetes or CNI upgrades.

Sources: Kubernetes Security Checklist, Kubernetes Pod Security Standards, Kubernetes Secrets good practices, CIS Kubernetes Benchmark.