Info

carbon% /usr/local/m/versions/4.4/mongocryptd --bind_ip 1.2.3.4 Error parsing command line: unrecognised option '--bind_ip' try '/usr/local/m/versions/4.4/mongocryptd --help' for more information Without --bind_ip, it is impossible to run mongocryptd in a docker container that is used by multiple application containers. User report here: https://stackoverflow.com/questions/61301673/connecting-to-a-mongocryptd-instance-in-docker-environment-with-mongoose/61310554

Top User Comments

mark.benvenuto commented on Wed, 29 Apr 2020 23:41:25 +0000: I do not believe there is a good solution to forwarding a localhost port bound in a container. I think the stackoverflow article you linked to should work. Otherwise they could use a privileged container and iptables (https://stackoverflow.com/questions/41706983/installing-iptables-in-docker-container-based-on-alpinelinux). On the multiple processes in container, you can run multiple processes in a container without init or systemd. While I understand that this is not considered a best practice for containers, this is the design for mongocryptd since we were worried about secrets getting exposed on the network. In terms of reaping, monogcryptd has builtin support for self reaping if it has no connections with --idleShutdownTimeoutSecs and correct usage of the lock file prevents multiple copies of it from running. oleg.pudeyev commented on Wed, 29 Apr 2020 01:41:29 +0000: Could you clarify what container networking technologies allow forwarding port bound only to a local interface? https://stackoverflow.com/questions/52513336/is-there-a-way-to-expose-a-docker-container-port-bound-to-127-0-0-1-to-host lists some workarounds, none of which appear to be blessed as a good solution. > The best solution I think, especially in a Docker environment, there is an expectation that containers are very much lightweight. I wouldn't automatically call a solution that doubles the number of processes running per container (with associated memory consumption growth, etc.) the best. In fact, it is my understanding that running mongocryptd in "automatic" driver-spawned mode requires the system to have a running init process, which Docker does not provide by default. Running an init process triples the number of processes in a container (application + mongocryptd + init). Without the init process, the dead (due to inactivity) mongocryptds will not be reaped and would essentially be a memory leak, eventually I imagine making the entire container run out of memory. mark.benvenuto commented on Wed, 29 Apr 2020 01:24:18 +0000: MongoCryptD only binds to locahost since it does not support TLS. It does not support --bind_ip as result. This was a design decision to simplify deployment of mongocryptd and also mitigate issues with mongocryptd processes that are not under control of the client seeing sensitive information. If you need to forward this in a container, I believe their are container networking technologies which can be used to forward the port. If that does not work, you can use a program like socat to forward the port off machine. This is dangerous and unsupported. The best solution is to simply run mongocryptd in the same container as the application.

Steps to Reproduce