Five Kubernetes security mistakes we see in every audit

Kubernetes is powerful, but its defaults are tuned for flexibility, not safety. Across the clusters we review, a small set of issues account for most of the real risk. Fixing them is usually quick and pays for itself immediately.

1. Running containers as root

Most images still run as root by default. Set runAsNonRoot, drop unnecessary Linux capabilities, and use a read-only root filesystem wherever you can. These are one-line additions to your security context that dramatically reduce blast radius.

2. Over-permissive RBAC

Wildcard roles and cluster-admin bindings are convenient and dangerous. Audit who can do what, replace wildcards with explicit verbs and resources, and prefer namespaced roles over cluster-wide ones.

3. No network policies

By default every pod can talk to every other pod. A default-deny network policy plus explicit allow rules turns lateral movement from trivial into hard.

4. Secrets in plain manifests

Base64 is not encryption. Use a real secrets manager, enable encryption at rest for etcd, and keep secrets out of your Git history with sealed secrets or an external store.

5. Skipping admission control

Policy engines like OPA Gatekeeper or Kyverno let you enforce these rules automatically, so insecure workloads never reach the cluster in the first place. Start in audit mode, then enforce.

None of these require a big project — each is an afternoon of work that meaningfully raises your security baseline. If you want a second set of eyes on your cluster, get in touch.