I work in cloud infrastructure and often see customers place their clusters behind cloud-provider security services, vulnerability scanners, and network firewalls. I recently heard someone say that most people know how to deploy pods, but very few know how to secure them. That made me wonder what security gaps remain after those controls are in place. What Kubernetes-specific practices are considered part of securing a pod, and which risks are not covered by perimeter firewalls or image scanners?
3 Answers
Security starts before the pod is created. Use hardened, minimal images, pin images by digest instead of relying on mutable tags, keep dependencies updated, and avoid downloading untrusted content during builds or at runtime. Image scanning helps find known vulnerabilities, but it does not guarantee that the image is minimal or that the running container has safe permissions. Pod Security Standards, admission policies, and runtime tools can enforce many of these settings consistently.
Perimeter firewalls and cloud security tools mostly protect the cluster boundary or scan images before deployment. Pod security focuses on what a container can do after it starts, especially if the workload is compromised. Common controls include running as a non-root user, dropping unnecessary Linux capabilities, disabling privilege escalation, using read-only filesystems where possible, applying seccomp or AppArmor profiles, avoiding privileged containers and host mounts, and using minimal service-account permissions.
So the main idea is defense in depth: protect the cluster from the outside, then limit each workload's privileges in case something gets through.
A major missing layer is east-west traffic inside the cluster. Without NetworkPolicies, pods may be able to communicate with many other pods by default, so an attacker who compromises one workload can attempt lateral movement. You should explicitly allow only the connections each application needs, protect access to the Kubernetes API, and disable automounting of service-account tokens when a pod does not need them. Resource requests, limits, and quotas also help prevent noisy workloads or resource exhaustion from destabilizing the cluster.
Even the default service account can be risky if its token is mounted everywhere. It may have limited permissions, but disabling unnecessary tokens still removes an easy credential from compromised containers.
The same principle applies to application traffic: if a frontend only needs to reach a specific API and the API only needs the database, those paths should be explicitly allowed rather than leaving every pod reachable by default.