Hacker News Reader

Yeah, it seems like there's a weird inbetween phase when projects go from "awesome tool used and loved by some core people" to "this is the new normal, it's everywhere" where these issues get lost. I could see back in 2014 moby not really feeling like the quirks of ufw & iptables were its problem. But now in 2021 with how many millions of times docker run is used per day on machines all across the internet... it's just irresponsible security. It sucks, it isn't really docker's problem in the first place... but it's reality and someone needs to grab the hot potato and keep it from burning people for the good of us all.

I know the CICD code I wrote and manage at work launches approximately a million docker containers a day, so I suspect the total number of docker containers used per day is well into the billions.

Do tell about where you would need a million docker images for a CICD pipeline.. It's either many apps, or some very complicated pipelines

Or many builds of the same app. Think compatibility matrix testing: take one suite of tests and run them against every one of hundreds of permutations of versions of their dependencies, one container each.

Not GP, just hypothesizing. This is what Travis matrixes do, for example.

We have a suite of about two thousand integration tests and we run each test in its own docker container for isolation purposes. Multiply by 500 jobs a day and you get to a million containers.

I agree, there is a huge difference what one should expect from a early OS project and what one should be able to expect from billion dollar companies.

But it seems that without external pressure (regulatory?), it's not getting fixed at either end.

I spun up Mongo on a cloud VM a while back to assess viability/suitability, it was Meow'd within 30 seconds, absolutely insane.

I shut it down and moved on, we don't use Mongo to date.

Did you follow our guidelines? https://docs.mongodb.com/manual/administration/security-chec...

You must have compromised the binding to localhost in some way to allow this to happen as MongoDB only listens on localhost by default.

> You must have compromised the binding to localhost in some way to allow this to happen as MongoDB only listens on localhost by default.

Serious: Listening on localhost-only works in dev environments only. In production, it is not the norm to run the application on the same host as Mongo, especially given what a resource hog Mongo is. So, for practical purposes, listen-on-localhost is actually an obstacle is needs to be disabled first-thing anyway.

You guys know this too, because you do exactly this (and a lot more) on that Atlas thing you guys love to upsell everyone and their grandmother on.

Honestly, it is telling that this is the only defence you could provide — that you listen on localhost — and not anything _actually_ secure in prod. Must come in handy when upselling Atlas, I guess, that your the default configuration conveniently omits everything.

> Did you follow our guidelines? https://docs.mongodb.com/manual/administration/security-chec...

Snark: maybe they couldn't trust your guidelines because MongoDB the company is a known blatant liar[1].

1: https://twitter.com/jepsen_io/status/1255867265997844484

There wasn't a lot of information in your previous post. As I pointed out there are a comprehensive set of guidelines for enforcing security. Our defaults make it difficult to accidentally expose your data these days. However if you do add a MongoDB database to a public IP address we strongly encourage you to add a strong password. Better still do not expose your database on the public internet. Put it behind a firewall with auth enabled, secure it with a certificate and only allow access to named IP addresses.

> There wasn't a lot of information in your previous post.

As the first paragraph of my comment says: listen-on-localhost is untenable in production. Unless, of course, you guys seriously believe people should be running their production applications on the same host as mongo daemons. Honestly, I wouldn't be greatly surprised if you guys believe that.

> Our defaults make it difficult to ...

You have one (1) default that does that. Singular. None of your other defaults do that. And, as I've said above, that one (1) default is also useless, because it's one of the first things that need to be disabled in production anyway.

> However if you do add a MongoDB database to a public IP address we strongly encourage you to add a strong password. Better still do not expose your database on the public internet. Put it behind a firewall with auth enabled, secure it with a certificate and only allow access to named IP addresses.

Everybody knows this. You aren't adding anything new. Nobody's claiming MongoDB _cannot_ be secured. Everybody knows that it can be. The question, instead, is: why does every user of MongoDB even need to make it secure?!

I doubt you can answer that honestly, but plenty of us suspect we know it anyway: because MongoDB Inc. "cares" a lot more about developer experience, than it does about their data.

Postgres containers won't start unless a password is set. Be like postgres.

Given the famed hatred MongoDB Inc. has for Postgres, I half suspect they might be doing this partly out of pure spite towards Postgres. "Eww, no. We won't do that. _Postgres_ does that."

> Listening on localhost-only works in dev environments only

You're awfully arrogant for someone who has no clue in how to properly architect systems.

If you're using Kubernetes then it's very common to have a service mesh in a Production environment to enforce certain safeguards e.g. mutual TLS and provide circuit breaking, auditing, logging etc. In which case MongoDB would be running on localhost.

If you're not using Kubernetes then it's also common to have some form of middleware to achieve the same as above e.g. HAProxy, F5. Again, in which case MongoDB would be running on localhost.

So I need either 1. Kubernetes and a service mesh; or 2. HAProxy or F5; just to secure access to a database?! Especially when the database is already capable of TLS mutual auth?! Is this what your claim of skill in "how to properly architect systems" comes from?! Needless over-architecting?

Look, I've done my fair share of fronting services (including DBs) using TLS/SSH proxies and load balancers. When I needed them. But the question isn't if any of that can be done or needs be done. The question is: Why does MongoDB, which has all of these security support built-in, not enable them out of the box?

And your answer to that is ... throw more stuff on top of it?! Are you seriously claiming that every production user of MongoDB should take on so much software surface area just to fix the broken defaults Mongo ships with?! This is worse than what even MongoDB Inc. does; at least they document how to enable security (lol, what a concept) and merely automatically blame the user for all lapses.

And no, k8s service meshes and LBs in front of DBs aren't nearly as common in production as you're claiming.

I've worked for a number of the Fortune 10, banks, telcos etc.

Everyone has put some sort of middleware between their applications and databases.

Your claim that no one is running databases on localhost is simply your ignorance.

> I've worked for a number of the Fortune 10, banks, telcos etc.

Are you seriously claiming that the only production users of DBs are "Fortune 10, banks, telcos"?! Or are you claiming that because those guys do something a certain way, everyone else must also do it like that?! This is a weird variation of the Argument to Authority, and even more flawed than the original.

> Everyone has put some sort of middleware between their applications and databases.

Really? "Everyone"? Or are you just generalising the state of the entire industry based off of your limited experience with a small number of players in it?

> Your claim that no one is running databases on localhost

I made no such claim. I said it's "not the norm" and that it's "untenable", not that "no one does it". It doesn't matter that there are a few examples you've seen that do; they're not representative of the entire industry.

On the other hand, for the vast majority of the industry who run databases in production, my claims hold.

The vast majority of the industry, that does not include "Fortune 10, banks, telcos".

I ran the Docker image, I'm not sure which docs I followed, it was a while ago, but in this case listening on localhost doesn't really apply.

Docker, as we know will open exposed container ports to the world, that shouldn't really be the baseline though for not having your instance compromised in less time than it takes to enter an iptables rule correctly, or read the guidelines.

I'm not trying to place blame, it was an exploratory endeavour anyway, but Meow existed because security in Mongo is a guideline and not a rule

As someone who builds secure software solutions for a living it doesn't thrill me that security is often an "optional extra" (looking at you elastic).

If I asked our customers/users the same question you just asked me, and then followed it up with "You must have compromised...", I'd be in hot water.

A combination of factors contributed to us choosing not to use Mongo at the time, if we have such a need again, it will be considered without prejudice.

That "you must have compromised.." was in relation to the comment by pritambaral not your overall analysis.

It is demonstrably obvious this is a lie:

The first time I commented in this whole discussion was _in reply to_ your "you must have compromised ...".

> Docker, as we know will open exposed container ports to the world

Only if you choose to explicitly expose them.

In which case the fault is entirely with you.

> So I wouldn't be surprised if we at some point see some attempts to keep sw-developers accountable for what they give out.

Wow, the level of entitlement around open source is appalling. People download and run shit for free and get mad that they didn’t configure it right and want the government to go after the maintainers.

I can’t wait for the day where us open source devs have to contribute patches via pseudonyms and tor because they aren’t “government compliant”.

This isn't an entitlement issue; it's a public safety issue.

If some philanthropist were to give out free bicycles to everyone, but it turns out that unless you tighten a bolt one of the main support bars will likely snap and could even impale you, the government would rightfully go after them regardless of any "without warranty" disclaimer or EULA.

This is already well-trodden legal ground in the physical space; it's just a matter of bringing it into the virtual space.

It will kill open source. And a lot of other small company software development.

No it won't. The example GP has given didn't kill any industry either.

Open source projects seldom get popular overnight. Responsibilities grow as you get more popular, that is all...

Software is very different than making bicycles. Anyone can make an open source project in their attic and promote it. You cannot do that with most (or any) other of those other examples as it takes actual factories etc.

That is the GP example. If I make 1 bike by hand and put that somewhere on the street, and someone takes it and breaks their legs, that is not my fault. Nor should it be. If I sell that 1 bike, that can be another story.

It will kill open source imho as if you, in your underwear in the attic are responsible for some code you write and put on GitHub, you won't write that code anymore because of the risk; but I don't want to find out who is right here.

Responsibilities should befall the person deploying the software. Aka if you write some software and throw in on GitHub, that should not do anything. But if I take that software and put it in my app or backend and takes people's money because of some bug, then I am the one who is responsible. And this is already the case anyway. No changes are needed.

I think we agree though as I think we are talking about the person who writes and deploys/sells the software: they should indeed be responsible and already are.

Ok so now it's the manufacturer's fault if you expose containers without authentication on internet, that users are fine with just "believing" that their firewall works as they expect without even testing: that's perfectly fine, manufacturer's responsibility!

Except with GDPR, which makes you responsible for having regular security testing, I mean, just an nmap after changing your infra, it takes 2 minutes, and yet when you don't take these 2 minutes you find a way to blame the manufacturer. I mean, don't you /know/ that bots are scanning the internet for open unauthenticated services, and still want to be taken seriously. Back in the days every kid was doing it to host warez you know.

I am definitely not arguing users should not be responsible for what they do. My point is that companies (especially billion dollar companies) can, and should be (more) secure by default.

I am also making the observation that this does not seem to get fixed by itself, rather it seems it needs regulation, which includes GDPR.

I’d argue that anyone that uses Mongo given those defaults is equally culpable

Mongo recruiters often reach out to me, I tell them that I'd never get that stain off my resume.