You moved to Kubernetes because you wanted portable, scalable infrastructure. You got it. You also got a much larger attack surface than most engineering teams realize, and a control plane that is opt-in secure rather than secure by default.
Most startups running Kubernetes in production are doing fewer than five of the basic security controls. Here are the ones that matter and the order to do them in.
The defaults you have to fix immediately
Containers running as root. Most images run as UID 0 by default. If an attacker escapes the container, they land as root on the node. Set a non-root user in your Dockerfiles and enforce it in pod specs with runAsNonRoot: true.
Privileged containers. Privileged containers can do almost anything the node can. There is almost never a legitimate reason for a workload to be privileged. Enforce a Pod Security Standard at the namespace level that blocks privileged mode.
Missing resource limits. Without CPU and memory limits, a single misbehaving pod can take down a node. Set sensible defaults at the LimitRange level so every pod has them whether or not the developer remembered.
Wide-open network policies. By default, every pod can talk to every other pod. Implement default-deny NetworkPolicies per namespace and allowlist specific ingress/egress. This single change limits blast radius dramatically when something does get compromised.
Image security
Your container images are a supply chain. Most teams treat them like static assets and ignore the security implications.
- Use minimal base images. Distroless, Alpine, or scratch images cut your attack surface by orders of magnitude versus full Ubuntu/Debian bases.
- Scan images on build. Trivy, Grype, or Snyk in your CI pipeline. Fail builds on high-severity CVEs in your direct dependencies.
- Pin image digests, not tags. latest changes. v1.2.3 can be repushed. Pin sha256 digests in production manifests to make sure you deploy what you reviewed.
- Sign your images. Sigstore/cosign makes image signing nearly free. Verify signatures at admission with policy-controller.
Cluster-level controls
Beyond pod-level basics, a few cluster-level controls dramatically reduce risk.
RBAC, properly scoped. The default service accounts have more access than they need. Create per-workload service accounts with the minimum required permissions. Audit cluster-admin grants regularly. Strip them where you can.
Admission control. Use an admission controller (Kyverno or OPA Gatekeeper) to enforce policies at deploy time, not as a manual review. Block privileged pods, require signed images, enforce labels, fail closed.
Secrets management. Stop putting secrets in environment variables in plain Kubernetes Secrets (which are base64, not encrypted). Use a real secrets manager (AWS Secrets Manager, GCP Secret Manager, HashiCorp Vault) with workload identity for retrieval.
Audit logging. Enable Kubernetes audit logs. Ship them off-cluster to your SIEM or log aggregator. When something does go wrong, audit logs are usually how you reconstruct what happened.
What to monitor
The minimum runtime monitoring for production Kubernetes:
- Falco or equivalent for runtime threat detection (suspicious process execution, unexpected outbound connections, container escapes).
- Cloud provider audit logs for control plane access.
- Alerts on RBAC changes, especially anything granting cluster-admin.
- Alerts on new pod creation in sensitive namespaces (kube-system, prod data tiers).
None of this requires a security team. All of it is achievable in a few weeks of focused work. The teams that get breached on Kubernetes are not getting hit by exotic CVEs. They are getting hit by missing basics.
Need a Kubernetes security review?
We audit Kubernetes deployments against CIS benchmarks and real-world threat models, then help you fix what we find. Typical engagement: two weeks.
Book a review