Hi, The expectation is as the FDB docs say, it will be essential to provide perimeter security around your foundationdb cluster, you should not accept inbound connections to it from the outside world. It will be appropriate to allow inbound connections to the CouchDB port though, as that is where access control will be enforced. In practice, as with CouchDB 2.0, you don’t even typically do that. Instead there is a load balancer or reverse proxy that sits in front of the whole thing. The foundationdb cluster is behind the CouchDB processes and network access controls should ensure that users cannot contact fdb directly.
I expect we will strongly recommend the mutual TLS setup for multi-node clusters, though, as this avoids accidents but for single node installs (on your laptop, for example), the fdb server will run on the loopback interface only. The fdb-backed release of CouchDB will have updated documentation on how to secure your cluster, for sure. It is not yet decided how far the release itself will go in configuring and securing the foundationDB cluster. B. > On 25 Jan 2019, at 07:31, Michael Fair <mich...@daclubhouse.net> wrote: > > 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
