readonly root inside container #7923
Comments
|
I am +1 for this and it's already able to be supported in libconatiner. Do you think we need to have the ability to specify tmpfs mounts first though via docker before we can do this? There will be some applications that need to write in |
|
I think you can take care of passing the equivalent of Fedora's RW_MOUNT=/var/lib/stateless/writable and STATE_MOUNT=/var/lib/stateless/state through to the container using --volume flags. There's still some configuration required. I think this is probably something that should go in the Dockerfile, but maybe people want to be able to change their minds at docker run time. Taking a look at Fedora's rwtab today, you have 3 types of configuration: dirs /var/log dirs means take all the directories in the base image and make them available for read/write, either on top of a tmpfs or on top of the RW_MOUNT directory. empty means the same for the directory, but ignore any subdirectories that might exist in the base image. files gives you a read/write file with the initial contents from the image. So if you do this in the Dockerfile, each of these might become a RWTAB line (need a better name) you'd also have a RW_MOUNT specifying a directory, where if it isn't set, means you get a tmpfs. And then maybe docker run takes a --rwmount flag. Maybe you also need to be able to do rwtab entries on the command line. Maybe --rw-dir --rw-empty --rw-files? From my perspective, the main reason it's nice to have this in the Dockerfile is that it simplifies the arguments needed to get one of these containers running with the right rw and state mounts and rwtab entries, without changing anything in the Mesos API for running Docker containers. |
|
👍 Read-only rootfs would be very useful. It enforces usage of containers and guarantees you don't depend on the data stored in the container. It also make maintaining and cleaning up easier. See also #2710 |
|
@discordianfish this is already possible in libcontainer. Can you think of a proposal for a flag, maybe: |
|
@crosbymichael --readonly sounds good! |
|
Read-only containers are more secure as well. |
|
@crosbymichael Is this something we want and just nobody has implemented it? If so, I can do that. |
|
@discordianfish it's implemented ( in libcontainer ), we just need some agreement on the flag. Let me discuss with my fellow maintainers and see if we can get this sorted out and in for 1.5 |
|
I think this will probably depend on |
|
@discordianfish go ahead and implement --readonly if you have time. For it to be in docker 1.5 it needs to be done this week, if you don't have time I can implement it. |
|
@crosbymichael I would love to implement it, but have no time this week. So if you have time, go for it. |
Add a --readonly flag to allow the container's root filesystem to be mounted as readonly. This can be used in combination with volumes to force a container's process to only write to locations that will be persisted. This is useful in many cases where the admin controls where they would like developers to write files and error on any other locations. Closes moby#7923 Closes moby#8752 Signed-off-by: Michael Crosby <crosbymichael@gmail.com>
Fedora has supported the concept of a readonly root for a long time as way of making a system more stateless.
We have used this with boot-from-initramfs deployments to make sure that no service accidentally writes somewhere it shouldn't. I think this could also be useful within containers to make sure that services that run in the container are properly configured to either write data to tmpfs-backed temporary directories or to r/w volumes shared from outside with --volume and nowhere else.
The main Fedora script is here: https://git.fedorahosted.org/cgit/initscripts.git/tree/systemd/fedora-readonly
A writeup of how it works: https://warewolf.github.io/blog/2013/10/12/setting-up-a-read-only-rootfs-fedora-box/
In a Docker context, I think the main things that would carry over are flags for docker run:
Does this sound like something that's interesting to support in Docker? If so, I could start looking at putting together the start of a pull request.
The text was updated successfully, but these errors were encountered: