As requested by @dadgar in #725. Adding support for --read-only, --cap-drop=ALL, --cap-add=SETUID and seccomp (when it comes) would go a long way to increase security of Docker containers running under Nomad. I think security is important and should not be something thats sprinkled on top of a product, but an integral part of it.
Support for seccomp was added in libcontainer recently and is probably available in docker engine 1.10+. This should go in the driver config as a list of capabilities that should be dropped or allowed.
Also, since exec driver uses libcontainer under the hood we should be able to do this for our exec based drivers as well.
@maticmeznar We won't be able to do this in time for 0.3, probably will come sometime in the future releases.
Great, thank you! I'll need this in a few months, so hopefully it will be available by then :)
As a followup to this, hashicorp vault needs --cap-add IPC_LOCK to work in a docker container(well to work properly anyway). adding capabilities would allow us to run vault inside of nomad.
we have a case that needs to specify --cap-drop=DAC_OVERRIDE. If this request can be done, that would be great!
seconding the IPC_LOCK requirement for Vault - it's the only thing stopping my running Vault via Nomad :)
Same here, I was happy today I could run vault with consul via docker-compose and now I realize I can't do the same via Nomad :(
Any update when it will be added?
Actually, I came to realise that the IPC_LOCK functionality isn't needed anyhow for Vault when run in Nomad. IPC_LOCK simply allows control over locking of memory to stop it being swapped out to swap. A little known fact of Nomad is that it automatically disabled swap for ALL jobs. Therefore, Vault in Nomad is safe :)
Hi 馃憢,
Any update or timeline on these features?
I'm working for my school and we are building our new CI environnement to automatically test students code. We use nomad to schedule our test runner. We need theses two features because we can't trust student code:
Let me know if I can help in any way!
Best regards.
@dethi you can use the QEMU driver( https://www.nomadproject.io/docs/drivers/qemu.html ) and can then further do restriction, inside the VM.
The Docker driver as run by Nomad is already pretty locked down compared to default docker. This ticket is about giving us the ability to unlock it down for the most part. I'd recommend your Dockerfile runs the processes as nobody(or some other user with no perms), you would probably be pretty well off (Using the USER directive in the Dockerfile).
Also I think it's awesome that you are giving students exposure to CI/CD already!
@dethi We would happily accept a PR for dropping capabilities. But anything that would add capabilities would require a more nuanced implementation that allows the operator to specify what capabilities may or may not be added.
Thanks guys for your answer.
@dadgar I'll work on it in the next couple of weeks!
--cap-add would be a great addition. We are starting to see some systemd enabled containers and planning to use some and we need to set --cap-add SYS_ADMIN to be able to run them.
Never mind... after reading this article I realized this is actually a bad idea! 馃槃
Any news about read-only mode for docker containers? I need this function to prevent any activity in containers with stateless apps. Also I would like to see support of tmpfs option to create writable directories for temporary data ( for example some kind of cache and so).
Bumping this a bit, specifically docker read-only mode would be nice to have soon'ish :)
If anyone want to give this a stab, it's a matter of exposing ReadonlyRootfs in the docker.HostConfig struct (docker src)
Any update on this. We need --cap-drop=ALL asap please.
Thanks for linking that issue @chronoslynx ! I think we have all of the features this issue asked for, so I'm going to close it. Please open a new issue if we missed anything!
Most helpful comment
Any news about read-only mode for docker containers? I need this function to prevent any activity in containers with stateless apps. Also I would like to see support of tmpfs option to create writable directories for temporary data ( for example some kind of cache and so).