In the spirit of discussing any potentially really serious drawbacks, I was reading through the FoundationDB documents when I came across this:
Not a security boundary Anyone who can connect to a FoundationDB cluster can read and write every key in the database. There is no user-level access control. External protections must be put into place to protect your database. And this StackOverflow question seems to confirm: https://stackoverflow.com/questions/51070230/foundationdb-authentication Umm, so what's the expectation here? What gets me is that it's also a network server that "accepts" inbound connections and they know this already... So if exposed on a public ip address (making some site-to-site redundancy configurations easier), the entire planet automagically has access to read/write to the entire database... To which I think the answer is: VPNs, Firewalls, and "Don't do that, it hurts" Which I think makes Couch a lot more complicated and less secure than it is... It sounds like the result of this is "any user on any Couch node or any FDB node can rewrite the entire FDB database", and that's assuming the machine's firewall is configured to restrict access to the relevant IP/PORT pairs by source address (otherwise the implication becomes anyone who can connect). I saw in the recent commits for the latest version a bunch of support for TLS, which seems to be echoed in the comment "use the mutual TLS support if you want to run a cluster in an untrusted network"... Will a Couch cluster also be required to create/maintain/manage the required cert files and configuration? Or is there some extra magic I'm not seeing somewhere that could prevent what seems like a 'local attacker' from maliciously wiping of the entire keystore? I like being able to just install CouchDB on a laptop and use the web UI to secure it up a bit; this seems to risk opening up access directly to the keystore... Questions/Comments? Thanks, Mike
