That might be true, but regardless of docker (or other, similar solutions), shouldn't MongoDB have had auth protection?
Yes, root account password and access permissions should be changed upon a fresh install, but the real issue here is Docker's "helpfulness" by opening ports without explicit permission. That's absurd, and has no reasonable excuse.
> Installation of MySQL creates only a 'root'@'localhost' superuser account that has all privileges and can do anything.
It's only a local account. Sure, it would be great to have a password on it, but it's not "a completely open root account".
It has a password, which the user has to change, before they can do anything else. From that same page you linked:
""" For data directory initialization performed manually using mysqld --initialize, mysqld generates an initial random password, marks it expired, and writes it to the server error log. """
This is a feature and a dangerous one.
Our provisioning had to carefully manage the firewall during installation, because MySQL would be open to the world *while provisioning*. Often this is mere seconds or less, but on a reasonable popular webhosting, this is enough time for automated tools to take over the server. If, during that provisioning some other tool would start punching holes in the firewall you carefully manage from provisining, I would be enraged. I dislike Docker for a lot of reasons[0], and this kind of behaviour is one of them.
So, yes: what MySQL or MongoDB do is dangerous and poor security practice. But what Docker does is worse: it breaks the countermeasures you take and rely on. IF all your layers of protection are removed by poor security practices of a tool that says "yea, but you need more than just this one layer" you still have no protection.
[0] yet I do use it a lot on development-machines to run the services needed on localhost and not have to manage all those with apt/snap/brew or whatever they come with.
That's flat out wrong. You can't start MySQL/MariaDB docker images without either explicitly specifying a root password, have it generate a random one on the first start of the container, or explicitly allowing an empty password.
Regarding native installs of MySQL/MariaDB, the situation is a bit more murky, but at least the Ubuntu/Debian packages will ask you for a password during setup (and the bind-ip is 127.0.0.1 by default which means you'll have to mess around with conf.d files if you want to setup an externally-reachable server).
It's Docker's responsibility to not open firewall ports unless explicitly asked to do so.
Opening random ports without A) Telling the developer first, B) Requesting permission to do so, C) Explaining why Docker wants to do so and D) Providing the ability to "opt-out" of this insecure-by-default configuration - is very bad.
It doesn't matter how secure or insecure the software inside the container is... it shouldn't be allowed to communicate with the public unless the developer specifically requests it.
You are asking Docker to open firewall ports with the -p option, it explicitly even says in the manual that published ports will be reachable from everywhere that can access the IP you're publishing on (either default 0.0.0.0 or an IP of your choosing).
I don't have a horse in this race, as I don't use Docker for a plethora of reasons dating back to it's inception. There are plenty of far superior containers to use. Just adding this footgun to the list of reasons...
Regardless, a supposed "enterprise" tool shouldn't start changing your config in surprising ways, like punching firewall holes without explicitly being asked to do so. That's just crazy...
The packaging does the necessary setup for you, and modern MySQL has secure defaults anyway.
They had super lax security, making them easy to use for newbie devs, who are frequently scared/easily distracted by security settings.
I'm quite convinced the lack of security was by design. Growth hacking and all that. Get everyone onboard and once you have big business going on, you can focus on the minutiae of security, scaling, not losing data.
Node.js, PHP, Docker (heh!) most other popular techs did the same thing: super lax and frequently wrong defaults, just to get adoption.
As a startup it seems you either choose right/security or wrong/money :-)
The development strategy did work, though.
right/no users or wrong/yes users
Not much point being right if no one uses the product :)
My point was: why didn't the author of the article enable the use of authorisation? To rely on only a firewall is just stupid.
What system, framework or stack are you using that stores the code of the job in the database? I'm curious, because I can imagine it solves some issues, e.g. deploying new code while allowing old code to finish running and scheduled jobs.
Also, if you have stuff like this in Redis, which will get picked up by a job runner:
{"runjob": "foojob", "params": ["one", "two"]}
- run jobs that aren’t supposed to run (removing an account for example, is that’s scheduled after a 2 week grace period) maybe an export or import job. Can be anything of course
- if your job runner allows scripts, or arbitrary class methods, you can do whatever you want
- you can remove jobs if you feel like it
- if you can escape redis because of whatever exploit, you now have access to the internal network
In general I use sidekiq, but resque and inspired implementations generally work on simply calling perform(), so any class with such a method can be called, depending on the typesystem.
The biggest two issues are the ability to perform any defined task, and the larger attack surface of an exposed redis server
And the hacker can still delete your database or steal your data. He will simply download the datafiles and then delete those data from the server. Drop database done without a database password. And no, databases aren't kept encrypted on the server.
So let’s start blaming every piece of software that listens to localhost, but is exposed by docker.
Not a fan of mongo, but the defaults are way better than before.
Docker needs to fix their defaults
Looks like the author is ahead of both us. Later in the post he mentions both a planned transition to a VPC, and plans to beef up the security of MongoDB itself.