The "best" location for Volumes defined on docker-compose file

General Discussions
,
1

Hello,
I am currently using Docker on Linux (Ubuntu server 22), and I deploy my container by a local dockerfile.
Inside that file I have defined my Volumes with the various configuration files, which I mount on each Container I need. Everything is working fine with the Volumes stored on the folder “/home/[MY USER]/volumes/”, but I am wondering if that is the best way (or at least the expected) to proceed.
For security purpose (as I have a couple of passwords definite there), I would like to put on “/root/Volumes/” folder, but I am worried some Containers may not have access there.

So, where do you usually store your local Volumes and what do you suggest?

Regards,

2

It looks like you are talking about bind mounts. Unless you are running rootless Docker, (by default) all users will be able to access any file on the host as root. So the question is whether the user inside the container can access it or not. You need to set the ownership and permissions properly.

3

Hello @rimelek,
Thank you for getting back.

It looks like you are talking about bind mounts.

I am pretty new to Docker and I am worried to not using the correct naming for it. But basically on my docker-compose file I have set the following expressions:
volumes:
- ./volumes/config_files:/etc/folder
And that is what I am asking :slight_smile:

Unless you are running rootless Docker, (by default) all users will be able to access any file on the host as root.

As I didn’t make any specific changes Docker should run as root.

So the question is whether the user inside the container can access it or not. You need to set the ownership and permissions properly.

This is exactly my question: the point would be run the containers with the lowest permissions as possible (e.g. not root) but at the same time to give it access to all the files on the Volumes by bind mounts.
So, what is the best solution (also considering the security) to achieve that?

Regards,

4

Sorry for 3 days delay.

That’s tthe bind mount, yes.

Well, the best would probably be reading the passwords from a database like hashicorp vault, but I have done that yet with Docker. Let’s see what I have done when I chose a simple solution on a server only I had access to so only I had access to the docker command.

I havestored the data somewhere in /srv/volumes/ so it didn’t have to be a home. I set the permissions on this folder so it was not “executable” by anyone, but the owner, root.

chown 0700 /srv/volumes

Note: In case of folders, the “executable” flag means “can list entries in that folder” so nobody could run cd /srv/volumes only me (well, nobody else were there).

Since Docker ran as root, it didn’t affect the volume mount so other users couldn’t have use the docker command or cd into that folder.

That is one solution if you want a simple one. It is basically what you are trying to do as the home folders are probably not “executable” by anyone except the owner.

You could use secrets, but that requires Docker Swarm

You don’t necessarily need to run the containers in Swarm but it has to be enabled. At least I had to when I last used it. Docker Compose can also use secrets, however, I am not sure how it is different from Swarm. If I remember correctly, it is different.

And there is HashiCorp Vault that I mentioned. I have shared this video somewhere on the forum in the past, but It could be a little outdated now

And you can find other blog posts about it

HashiCorp Vault is probably way too complicated for your use case, but it is good to know about it.

5

Having designed many containers in the past, I did this during my testing phase, but I would, now, advise against utilizing Docker as a root user, as any user can operate Docker containers successfully, if configured appropriately, and it makes it really complicated to track down key necessities in the container, and also often led me to incorporate slopy work-arounds that weren’t necessary;
The entire point of Docker is fundamentally to reduce workload/resource utilization.

6

What do you mean by “this”?

Did you just want to share that you would not run the Docker daemon as root or you would not run the process inside the continer as root?

Docker can run multiple ways and indeed there are recommendations for better security, but the “best” solution is not always the most secure. It depends on where and what it is used for.

Well, if it is configured appropriately, people who are not trusted, can’t use it. At least not the rootful Docker, maybe just the rootless Docker.

I am not sure I understood you correctly. I don’t think we can discuss every security considerations in this topic, but every opinion, recommendation is valuable :+1: so if you feel you have a recommendation related to the question, please add some details what you would recommend or exactly which previously mentioned option is wrong.

1 Like
7

Thanks for getting back.
Your environment seems pretty similar to store the Volumes (bind mounts) in the /root directory.
Or using aCIFS share like I was talking on this topic (mounting it as file_mode=0700,dir_mode=0700).

Correct.
At least per the default settings.

Indeed, I was taking a look but it may not worth the complexity.

That seems a rule valid for everything running as root that can be run as with lower permissions.

Regards

1 Like
8

Hi Rimelek,

By ‘this’ I meant operating the Docker daemon as a root user. It got messy quickly, and made things difficult to manage.

Inside the container is a contained/controlled environment, and can be run any way one chooses to, although I always ran internal processes by non-root users as well, as software products are complex, and can be written irresponsibly;
I operated within my containers the same way I would operate a process within Linux itself, as a non-root user.
As I operated within a security company, the ‘best’ solution was always the one that security guided towards; One of least privilege.

‘Well if it is configured appropriately, people who are not trusted can’t use it. At least not the rootful Docker, maybe just the rootless Docker.’
~ I operated my server as rootless, such that containers operate as regular Linux users.
The Docker daemon was running as a non-root as soon as this was possible post Docker v19.03;

1 Like
9

Thank you everyone for your contribution!

1 Like