How to properly organize shared mounting volumes in docker?

Question

File systems

There is a directory with a certain structure, not necessarily stored explicitly on the host.
There are two different docker images.
It is necessary that this directory be connected to one place when creating the container of the first image and to the second - the second.
It is necessary that individual subdirectories be available in the host under a different path, and you cannot use ls -s.
You need to make any changes at any of these three points (attached in the first and second containers, in the host directories associated with individual subdirectories of the structure).
If there was no need for access from the host, I would create a volume and then mount it in two containers.
I tried to do this: I create a directory on the host (say, / shared), I mount it as it is in two containers, then I mount it on the host

mount --bind /shared/<путь к поддиректории> <путь, по которому поддиректория должна быть доступна на хосте>

The problem is that you have to keep a list of all mount-binds in case the machine is overloaded, and you cannot mount in the reverse order (say, there is already a /project directory on the host, but you need to put it in the /shared/user/data/project subdirectory, then you can't mount-bind right away, you have to first mv /project /shared/user/data/projectand then mount --bind /shared/user/data/project /project).
There is also an opinion that directly mounting a host directory into a container creates a security hole.
Question: how would it be more correct to organize a shared mountable partition so that the security does not suffer and it is convenient to work?

Answer 1

Can involve another entity?
Let's say deploy an NFS server and mount its shared folder to both the host and the containers.
There are enough examples of using nfs on the network ..

Answer 2

1. There is no special meaning in bind mount, because the named volume is also available through the host fs in the /var/lib/docker/volumes/
directory and setting the startup order between them. Docker, unfortunately, does not solve this problem by itself. And for that matter - are you sure that you need a docker? In simple cases, the chroot environment solves the problem of isolation, and systemd brought namespaces and isolation. And even a full-fledged container like nspawn, controlled via machinectl