Enable mongodb IP whitelist

[xmunoz]

The application is deployed on Heroku, which doesn't offer static IPs. Configure a static IP for each deployment, and whitelist that IP address on the mongodb cluster firewall.

[colinxfleming]

hey @xmunoz , what's the state of the world on this front? I think I've seen a PR but feel like I've also seen chatter/an email that this is more pain than it's probably worth given the cost, technical hassle, and looming possibility of someday being Children of Postgres. Should we consider this still live (in which case, how can I help?) or has this gradually drifted into wontfix territory?

[xmunoz]

I think it's drifting in the "won't fix" direction. Take a look at the attached PR for a sample implementation. Outstanding questions:

1. Is this even worth it, given that we would need to pay for more quota than we initially anticipated
2. Figuring out how to circumvent the tunneling for local development, which the attached PR does not have a solution for.

[colinxfleming]

big yikes @ the local development bullet. I'm def interested in @lomky and @harumhelmy 's opinions on this, but kinda feels like this would be double the cost to have only a slightly better security stance?

In other words, inclined to wontfix but want opinions from the people who have been leading the project first!

[lomky]

File me under very frustrated and leaning strongly to the blissful world of Postgres. Whats the sttae of that big ol lift? week/month/6mo/1y+ out, assuming we focused it?

[colinxfleming]

6m would be my guess - my research branch indicated that we could get things working but it's hard and really sucks up time and energy.

[xmunoz]

I'm a bit confused by the Postgres remark. Even if Daria were using some kind of hosted Postgres solution, the concern about open network access would still need to be addressed in a similar way (e.g. setting a static IP for the app). If anything, the real culprit here is Heroku, which makes the process of configuring a private subnet or static IP expensive and cumbersome.

[colinxfleming]

@xmunoz has rightly pointed out that I've put the cart before the horse here, and that the root cause is heroku making static IP setting difficult to impossible. So scratch what I said about a postgres swap addressing the root cause of this issue.

That said, it does feel like this is really hard and costs more for not that much additional benefit, so doing nothing still feels like the default. @lomky let's talk about this when we check in tmw.

[colinxfleming]

@lomky and I did in fact talk about this when we checked in! I think our consensus was that while fixing this is almost certainly a cure worse than the disease, we'd feel like world class dingdongs if we got hit by it.

Our consensus was that the primary point of this would be to protect against brute force attacks (e.g. just hucking combos of logins and passwords until it found something good) - stuff like cred leaks felt less scary to us since these creds are kinda buried in heroku configs. It wasn't super clear whether or not mongo atlas had some separate way of dealing with that which would make that not an avenue, kind of like how we have rack-attack, so if mongo atlas DOES have something like this we can squash this and feel amazing about it. if it doesn't, then

I think realistically even if that isn't the case then we probably mercy kill this because of the complexity, but this is worth running down before we do I think.

[colinxfleming]

I settled down to do this tonight -- I tried to connect via CLI to see what would happen if I tried to brute force. Got some pretty promising results when I initially tried to log in (with proper creds, even):

$ mongo --host SANDBOXHOST -u SANDBOXUSER -p SANDBOXPASS 
MongoDB shell version v4.2.3
connecting to: mongodb://SANDBOXHOST:SANDBOXPORT/?compressors=disabled&gssapiServiceName=mongodb

*** It looks like this is a MongoDB Atlas cluster. Please ensure that your IP whitelist allows connections from your network.

2020-12-03T23:08:48.697-0500 E  QUERY    [js] Error: couldn't connect to server SANDBOXHOST:SANDBOXPORT, connection attempt failed: HostNotFound: Could not find address for SANDBOXHOST:SANDBOXPORT: SocketException: Host not found (authoritative) :
connect@src/mongo/shell/mongo.js:341:17
@(connect):2:6
2020-12-03T23:08:48.701-0500 F  -        [main] exception: connect failed
2020-12-03T23:08:48.701-0500 E  -        [main] exiting with code 1

I wonder if there's some under the hood stuff where heroku is on an auth'd IP allowlist or something. Either way I take this to be a promising sign that we're okay to declare victory on this and move on with our lives, secure in the knowledge that some confluence of heroku/atlas has this covered, somehow?

@xmunoz and @lomky - what do you think, killable?

[xmunoz]

Hmm, interesting. Let me look into this a bit more today. I have some time in the afternoon.

[xmunoz]

Yup, I was definitely able to log in from my home network. There is no IP whitelist protection out of the box.

$ mongo "mongodb+srv://USERNAME:PASSWORD@sandbox.lku34.mongodb.net/DB?retryWrites=true&w=majority"
MongoDB Enterprise atlas-v75uu4-shard-0:PRIMARY> show collections;
archived_patients
audit_trails
clinics
configs
events
patients
sessions
users

[xmunoz]

I'm fine doing whatever you decide. If/when you close this issue, make sure to decline the accompanying PR: #2050

[xmunoz]

No longer relevant