Considering updating the documentation to state that the default configuration of this container is insecure

[godmar]

Like tens of thousands of other MongoDB users, we were ransomed. This is embarrassing, especially for me who had told my developers that it's extremely unlikely that a widely used piece of database software distributed in 2023 would have insecure defaults. Yet it happened.

To recap:

• MongoDB by default binds to a local port
• When run inside the container, however, it must bind to an interface that can be exposed to outside the container
• When a user uses Docker's -p flag in its default incantation, the port is publicly exposed
• Because docker writes straight to iptables, this happens even if a firewall is set up
• This container ships in a configuration where authentication is disabled

This issue appears to be well known to the developers, but so far there is no mentioning of this glaring problem on the Dockerhub page of this container.

This behavior breaks expectations, and although not all blame lies with MongoDB's lack of a password in the default configuration - Docker's default behavior to assume -p 0.0.0.0:host:container is to blame as well - it seems to me that an "official" image should warn about this trap which is easy to fall into.

Please consider updating your documentation. The current idea - which to me appears to just not mention the behavior that occurs on -p - and to bury the fact that authentication is disabled by default in the fine print is, in my view, suboptimal, to put it mildly.

[godmar]

I'd like to follow up on why I believe that the current behavior "breaks expectations."

When users install official versions of software using their package manager - say running apt-get install - they do not expect that the act of doing so by itself will expose their software unprotected to the world, even if their machine is connected to the Internet. That is, I'd argue, an expectation that's been in place for 10 years if not longer. In fact, when mongodb in 2017 introduced this default behavior this was - 6 years ago - already an outlier.

Now, when you package and distribute a piece of software in a container, you should be following similar rules. That is, the mere act of downloading and activating the software using commonly used steps should not leave you with a vulnerable installation. This should be true even if as a result of the installation your software is reachable via an exposed port. If, for whatever reason, there is an exception, it should be noted.

I did a small amount of research to see whether my expectations are off base. Here's what I found in 5 minutes of research:

• The mysql official docker image requires a password setup
• So does the postgres official docker image
• The official Couchbase container appears to involve a mandatory password setup before use
• Redis (which is primarily used for transient data and is probably less often run in a container) comes by default in a passwordless config. The docker page, however, includes a prominent warning:

which is easy to see as it is listed second right after "What is Redis?"

This shows, in my opinion, that if the call is made that software be distributed without a mandatory password setup process, at a minimum, users should be prominently informed about common pitfalls in canonical use. A strong case is also to be made to not allow use of the software until a mandatory setup has been completed.

Lastly, I'd like to add that users of such software as Discourse or Wordpress - which is also distributed in containerized form - have become accustomed to mandatory setup processes before the software can be used.

[godmar]

While a good start, that section is insufficient because it does not address the behavior on -p hostport:containerport. I suggest looking at the Redis documentation for an example to follow.

The pitfall here is not just that you ship with authentication disabled: it's that the common defense mechanism of binding to the loopback interface does not work inside a container. As soon as you create a network path to the container -- which you have to do to be able to use your software at all - you run the risk of exposing the database to the Internet.

PS: Perhaps you are skeptical that I called -p a canonical invocation when you (perhaps) assume that most everyone deploys either in private networks/closed environments, uses private docker networks, or understands the implications of exposing a port to software that in its native, non-containerized version binds to 127.0.0.1.

Here are some sources your users may consult if this issue is not addressed in your documentation:

[!CAUTION] Warning for anyone reading this - what's below is all ~wrong advice~ advice that is risky and insecure.

• Official documentation of Enterprise version of MongoDB
• How to run mongodb in a docker container in 5 minutes by a "docker captain"
• Another blog post advising the same
• one of many posts of forums.docker.com

[whalelines]

Thank you for the additional feedback.

Docker Official Images (DOI) are intended to provide access to a wide variety of software across a wide variety of use cases. The types of DOI, their variants, and configurations are driven by the open source communities that develop and use them. Many DOI, mongo included, are optimized for ease of use in the local development inner loop since this is where most developers first use the images. For use cases such as these, it is entirely appropriate to use the default configuration provided by the mongo DOI.

Your assertion that the content in links you provide is "wrong" is not entirely accurate. The information may be wrong or incomplete for production-ready, publicly accessible use cases, but one should not confuse a "get a container running in five minutes" guide or forum posting helping someone expose a port with a guide for running a production instance of a publicly accessible data store.

The DOI READMEs on Docker Hub are not intended to provide exhaustive documentation for running the provided software. In fact, the mongo README already exceeds Docker Hubs character limit for a README, which is why the supported tags section contains a link and not the full list of tags.

I understand your frustration given the experience you detail in the description of this issue. I'll work to revise the Security section to provide a stronger warning.

[godmar]

I really don't understand your hesitancy to explicitly mention (-p) the way the Redis documentation does.

You have changed mongodb's defaults, thus arming what others have called a Docker footgun.

Many DOI, mongo included, are optimized for ease of use in the local development inner loop since this is where most developers first use the images. For use cases such as these, it is entirely appropriate to use the default configuration provided by the mongo DOI.

I would have to ask what you mean by "local development" here. Does "local" imply to you a machine that's not on any network? What about a machine that's on a coffeeshop's local network? I would tend to disagree, and in fact even if this is the primary use case for a DOI (which I find counterintuitive also upon reflection), it's even more reason to warn.

I actually think the problem could be addressed with a slight tweak:

It is highly recommended to set a root user name and password if you plan on exposing your Mongo instance to the internet.

why not

It is highly recommended to set a root user name and password if you plan on exposing your Mongo instance to the Internet, such as by using docker's -p option.

(and yes, -p does not always expose to the (capital I) Internet, but here we're imprecise in a defensible direction.)

[whalelines]

The mongo DOI is intended to support a wide variety of use cases, many of which do not use docker run, do not result in exposing a port to the internet, etc. As such, what is defensible and what is not is subjective. What would mentioning -p mean to someone who uses Docker Compose or only runs workloads in Kubernetes? How is a developer running a mongo container in WSL on a private network supposed to interpret a warning about exposing a port to the internet? There are many excellent resources for dockerd, Docker networking, running MongoDB in production, etc. There is no way for a 25,000 character README on Docker Hub to address all the concerns related to these topics.

[godmar]

I think we're disagreeing about the urgency of the issue. I'm a bit surprised that the bad publicity mongodb + docker appears to be getting are of less concern to you than they would be to me if I were in your situation. (Some of the compromises of course first concerned mongodb in its old configuration, but as evidenced by the sources I included, such as the NewsBlur compromise, the compromises continue except now with the dockerized version.)

I'm also perplexed that you mention the limit of the README, given that the current README addresses a variety of topics that are arguably of much less concern.