Docker Community Forums

Share and learn in the Docker community.

Hey, I'm planning to use Docker for a large project, little concerned about security, can you help?

I’ve been playing with Docker from a while now, and I’m loving it every day.
So I recently decided that it might be a great idea to use it for the large project we’re doing.

As a part of our app feature, we will give terminal access to clients to the containers they own.
The host machine will have multiple containers for multiple clients. Is it possible for a client to gain unauthorized access to host machine or other client’s containers? In other words, are containers secured by default? … or is it something a docker hacker can easily do?

I understand that there can be exploits of this kind in future and that is not the context here, but I’m only looking for some tricks or methods which exists as of today that might allow this behavior.

Theoretically, yes. Easy, no. It all depends on how you set things up. One of the biggest attack surfaces in Dockerland is the Linux kernel itself, which you are by definition giving them access to by providing them shell access in a container.

Yes and no. They are run with a seccomp profile and have a restrictive filesystem, but also run as root (which is same root as on host) by default. So there are some nice confining features but some sharp edges as well.

“Easily”, probably not. It would require a more sophisticated attacker than Jane Average Docker User, but is still something you should be worrying about.

As with giving any user privileges to execute code on boxes you own, there will always be risk. But if you must, here’s some ways you can be safer:

  • Use USER to run containers as non-root
  • Use AppArmor/grsecurity/SELinux type functionality
  • Turn off networking functionality and caps (--net none, --cap-drop CAP_BLAH) if not needed in shell containers. If attacker can’t install new software their attack will be much harder.
  • Keep detailed auditing and logs of what gets executed on the servers
  • Don’t bind mount or otherwise expose resources from host / other containers in containers

Pretty much your standard “secure multi-user UNIX/Linux” layer cake with additional Docker icing really.

There’s probably more I’m forgetting and a variety of resources you can look up to research more. Check out

Can you give me such examples?

Do you mean non-root user inside container? or run docker daemon as non-root?
We wish to allow users to install their own packages in the containers.

If the file system access is limited by default by Docker, what additional security AppArmor can offer? I am not very experienced with AppArmor but what I know is that it runs based on matching file patterns etc.
(On a container there’s already a different file system which users shall have full access to)

Also I’m quoting your reply from another thread:

When you say ‘use docker’ do you mean launching commands like ‘docker run’ on host.
or accessing the container terminal directly?

The reason I ask is that we’re giving clients direct access to the container terminal (through browser based terminal) and not the host.

just before I saw this thread here) I posted a different issue raising the question whether CoreOs’s rkt is not by design the ‘safer’ container runtime?

I have much less understanding of the details as all posters in this issue but understand the ‘being root’ inside a container is something ‘they’ just don’t do. So whether this was true (which I guess could cause a passionate argument) rkt was to be preferred to docker from a security perspective.

Naturally willing and happy to hear other opinions on this

confining features: isolated rootfs type environment, limited access to /proc, containers are run with decent default seccomp profile
sharp edges: containers run as root user by default and this is same uid as root on host, folks use bind-mounts willy nilly, network is not restricted, folks use things like --privileged without understanding the implications

Non-root user inside container. Allowing users to install arbitrary software almost by definition increases your attack surface, but maybe you could use user namespace remap to make “root” in containers not that same as root on host. It has its own issues however.

The file system access limiting I refer to is a “chroot”-like (actually pivot root) type environment. I’m talking about situations where user would find a way to access files they’re not supposed to be able to see or write to outside of the default isolated FS. Additional layer of protection to basically say “Hey X shouldn’t be writing here”.

The docker CLI or API

All tools have tradeoffs and every vendor is likely to tell you that their solution is the “most secure”. I suggest you figure out what your requirements are, gather information, focus only on technical facts over messaging and make an informed decision. Docker is extremely safe when used correctly. I have not used rkt so I cannot comment on it directly.

1 Like

I think that if you want to give people access to containers, you should get a good understanding of what containers are and how they work.

This is a extremely good talk by Jérôme Petazzoni that will explain the full concept.

1 Like

Security is concern for Docker container since it was launched. But techies have contributed a lot in community. One of the resource is this