Suppose an entire application stack runs on Kubernetes, with the database in one Pod and the web server in another Pod scheduled on the same node. The web server is exposed to the internet through a LoadBalancer Service, and clients connect over HTTPS. Does placing both workloads on the same physical machine create a security risk? In a traditional setup, the web tier and database might be separated onto different servers, so compromising the web server would not immediately provide access to the database host. What Kubernetes isolation and security controls address this concern, and what should be configured explicitly rather than assumed by default?
3 Answers
Kubernetes provides several layers of isolation, but containers are not the same security boundary as separate physical machines or virtual machines. Use node affinity or anti-affinity to ensure the web and database Pods cannot share a node when that separation matters. NetworkPolicies should also restrict database access so only the intended application workloads can connect to it, even if they happen to run on the same node.
Another option is to keep the public frontend outside the cluster, such as static assets behind object storage and a CDN, while exposing only an authenticated API through an API gateway or similar proxy. Serving the frontend inside Kubernetes can still be reasonable, but apply the usual controls: network policies, restricted service accounts, non-root containers, minimal capabilities, and strong runtime isolation. Also remember that a LoadBalancer Service does not necessarily mean every node is directly handling the application traffic, but co-locating sensitive workloads is still a placement decision worth controlling.
The answer depends on the threat model. Running workloads on the same node can be acceptable when the container and kernel isolation is strong enough for the risk you are accepting, but it should not be treated as secure automatically. For stronger isolation, separate nodes, use dedicated node pools, enforce anti-affinity, run with least privilege, and consider sandboxed runtimes such as gVisor. Kubernetes security is layered and has to be configured deliberately.
That makes sense. I was mainly concerned that the usual web-tier/database-tier separation is not automatic in Kubernetes. It sounds like the platform provides useful isolation, but I still need to explicitly design and enforce the boundaries for my threat model.