[SERVER-47693] mongocryptd does not recognize --bind_ip Created: 21/Apr/20  Updated: 27/Oct/23  Resolved: 29/Apr/20

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: 4.3.6
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: Oleg Pudeyev (Inactive) Assignee: Mark Benvenuto
Resolution: Works as Designed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Operating System: ALL
Sprint: Security 2020-05-04
Participants:

 Description   

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



 Comments   
Comment by Mark Benvenuto [ 29/Apr/20 ]

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.

Comment by Oleg Pudeyev (Inactive) [ 29/Apr/20 ]

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.

Comment by Mark Benvenuto [ 29/Apr/20 ]

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.

Generated at Thu Feb 08 05:14:58 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.