<p>TL;DR Kubernetes allows all containers to access all other containers on the entire cluster, this seems to greatly increase the security risks. How to mitigate?</p>

<p>Unlike <a href="https://www.docker.com/" rel="nofollow">Docker</a>, where one would usually only allow network connection between containers that need to communicate (via <code>--link</code>), each <em>Pod</em> on <a href="http://kubernetes.io/" rel="nofollow">Kubernetes</a> can access all other Pods on that <em>cluster</em>.</p>

<p>That means that for a standard Nginx + PHP/Python + MySQL/PostgreSQL, running on Kubernetes, a compromised Nginx would be able to access the database.</p>

<p>People used to run all those on a single machine, but that machine would have serious periodic updates (more than containers), and SELinux/AppArmor for serious people.</p>

<p>One can mitigate a bit the risks by having each project (if you have various independent websites for example) run each on their own cluster, but that seems wasteful.</p>

<p>The current <a href="https://github.com/kubernetes/kubernetes/blob/master/docs/design/security.md" rel="nofollow">Kubernetes security</a> seems to be very incomplete. Is there already a way to have a decent security for production?</p>

<p>As @tim-hockin says, we do plan to have a way to partition the network.  </p>

<p>But, IMO, for systems with more moving parts, (which is where Kubernetes should really shine), I think it will be better to focus on application security.  </p>

<p>Taking your three-layer example, the PHP pod should be authorized to talk to the database, but the Nginx pod should not.  So, if someone figures out a way to execute an arbitrary command in the Nginx pod, they might be able to send a request to the database Pod, but it should be rejected as not authorized.</p>

<p>I prefer the application-security approach because:</p>

<ul>
<li>I don't think the <code>--links</code> approach will scale well to 10s of different microservices or more.  It will be too hard to manage all the links.</li>
<li>I think as the number of devs in your org grows, you will need fine grained app-level security anyhow.  </li>
</ul>

<p>In terms of being like docker compose, it looks like docker compose currently only works on single machines, according to this page:
<a href="https://github.com/docker/compose/blob/master/SWARM.md" rel="nofollow">https://github.com/docker/compose/blob/master/SWARM.md</a></p>
