<p>I'm pretty newbie in kubernetes. I'm wondering what is the best production deployment scenario in kubernetes environments.</p>
<p>In the old school I was used to put in DMZ layer just the Web Server (e.g. Nginx or Apache) and in other layer (let's call it AS Layer). In this way just the web server are on DMZ and a malicious attack can be done just only on the Web Server VMs.</p>
<p>As far as I know this approach is no more needed in K8S deployments; this because K8S handles the network, pods and traffic by itself. So I was thinking about the most sure deployment scenario.</p>
<p>Let's suppose to have 3 worker nodes and 3 master nodes. I actually deploy my solution like in this picture:
<a href="https://i.stack.imgur.com/w2mxq.png" rel="nofollow noreferrer"><img src="https://i.stack.imgur.com/w2mxq.png" alt="Actual Deploy" /></a></p>
<p>As you can see I put in DMZ layer just the worker nodes; master nodes are in the AS layer.</p>
<p>What I'm wondering is: is this deployment &quot;sure enough&quot;. What I'm worried about is that is there is a malicious attack, the hacker will access to the worker node that is much different from a Web Server (where he can find just static files)</p>
<p>Another scenario, in &quot;old style school&quot; would be the following one:
<a href="https://i.stack.imgur.com/Y3une.png" rel="nofollow noreferrer"><img src="https://i.stack.imgur.com/Y3une.png" alt="Old School Dployment" /></a></p>
<p>In this case in the DMZ i just put Web Server and in the AS layer I put the full K8S cluster. But I don't know if this makes sense and how much feasible it is (every time a new POD/Service is added to the cluster maybe I should configure the Web Servers in DMZ in order to route requests to this new Service)</p>
<p>What do you think about the two approaches? Which one is the &quot;best&quot;?</p>
<p>Thank you</p>
<p>Angelo</p>

Angelo Immediata
<p>There's multiple ways to deal with this type of scenario in Kubernetes. I'm assuming you are dealing with an on-prem deployment.</p>
<ol>
<li>You could have a front-end cluster in the DMZ and an internal cluster inside the corporate firewall. This is the most secure option but it's expensive and time consuming to implement and manage.</li>
<li>You could create separate nodepools for the DMZ and the internal systems, and implement network policies to restrict the network traffic between them. I'd make sure that the DMZ nodepool isn't the default one, so that deployments need to target the DMZ pool explicitly.</li>
<li>Use only namespaces and network policies to restrict the traffic between pods running in the DMZ. This should be secure enough in most cases, as pods run in an operating system jail and are only able to access resources allocated to them.</li>
</ol>
<p>One important thing to keep in mind is that containers within pods should run under a normal user account and never under root, except maybe for init containers.</p>
<p>For more information see: <a href="https://kubernetes.io/docs/tasks/administer-cluster/securing-a-cluster/" rel="nofollow noreferrer">https://kubernetes.io/docs/tasks/administer-cluster/securing-a-cluster/</a></p>
