How to improve Kubernetes security especially inter-Pods?

3
votes

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?

Unlike Docker, where one would usually only allow network connection between containers that need to communicate (via --link), each Pod on Kubernetes can access all other Pods on that cluster.

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

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.

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.

The current Kubernetes security seems to be very incomplete. Is there already a way to have a decent security for production?

2
dockerkubernetesgoogle-kubernetes-engine
sounds like a job for a firewall - hanshenrik
@hanshenrik IPs are assigned dynamically by Kubernetes. It's possible to force a given IP but that's not meant for such use case. Also most Kubernetes cloud providers may not provide access to that. - Wernight
On a side-note be aware that Docker containers on the same host can access each other regardless of whether they are linked unless you start the daemon with -icc=false. - Adrian Mouat
@AdrianMouat Interesting, I didn't know about that. From the doc it looks like the default is --icc=true, which makes no sense at all to me. Thanks for pointing that out. - Wernight

2 Answers

1
votes

In the not-too-distant future we will introduce controls for network policy in Kubernetes. As of today that is not integrated, but several vendors (e.g. Weave, Calico) have policy engines that can work with Kubernetes.

1
votes

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

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.

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.

I prefer the application-security approach because:

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

In terms of being like docker compose, it looks like docker compose currently only works on single machines, according to this page: https://github.com/docker/compose/blob/master/SWARM.md