Secure or Insecure in Production with firewalls & loadbalancer SSL termination?

The production setup is typically done with proper firewalls and SSL all the way to the SLBs - termination happens there and then it is non-SSL communication. This approach has served well in case of standalone servers (app and DB). My question is, if I do not have multi-datacenter setup for CDB is it good to go the insecure way? Wondering if insecure is faster and better(good for CDB) or does it not matter or should it be strictly secure on Production.

Your recommendations please. (By the way, we encrypt PHI data and the likes of it as per standards and the DB is with a cloud provider who says the data volumes/directories are secure.)

Hi @guru,

Even when you’re firewalling properly, using insecure opens up some serious risks mapped out here. Also, securing a cluster doesn’t negatively impact its performance, so it really is the recommended approach for running CockroachDB in production.


I wish there was non-cert authentication like most databases. The involvement of certs adds a layer of work and gives a false sense of security. It’s great for users who do not use a firewall, but for those who do, if someone is able to ping your db, they probably got your certs already.

Total flexibility would be to just enable auth regardless of certs.

I just don’t understand why you would want to risk exposing peoples PHI.

I love all the work that cockroachlabs is doing to make CRDB as secure as possible, in it’s default settings. It makes it much easier to sleep at night knowing it was configured correctly the first time.


In what way “false”. Could you explain what you mean there?

When I access my servers over SSH I use SSH keys. My SSH client knows it’s talking to the right server and the server knows who my SSH client is. And all is encrypted.

Same applies when I am using a VPN with certs.

As far as I can tell using cockroach with certs is a secure as SSH or VPN. So what is the problem?

How does the ability to ping my servers give an attacker the chance to get my certs via cockroach?

I’m very happy with the way cockroach does things.

@bladefist part of the reason we don’t support password auth without TLS is that cockroachdb is a little different than “most databases”, namely in that it is distributed. Specifically the nodes in a cluster generally trust each other – e.g. if node3 connects to node1 and says hello, a equals 5 now, node1 believes it, and sets a=5.

If you want to ensure that only authorized users have access, in addition to checking their passwords during regular SQL connections, you also need to ensure only nodes you trust are allowed to join the cluster – otherwise someone could recompile a version that skips password verification and permission checks, tell it to join the cluster, and then circumvent the password checks and auth by connecting via that node.

Currently the way nodes authenticate each other is via TLS, so without TLS enabled, any node with network access can join the cluster, making password verification ineffective.

Obviously there are a couple ways you could try to fix this – you could do something like using the root user’s password to join a node to the cluster or something – but they add complexity to an area of the system where correctness is absolutely critical, so we don’t want to rush into a flawed solution. So far we have have yet to see a solution that’s as secure as just using TLS for everything.


I understand. I totally agree TLS is the most secure way to set things. My point is, that most peoples vlan are secure. Obviously adding TLS increases that security, but one could argue that if you have a secure VLAN and TLS, if an unauthorized server gained access to that VLAN, that you already have a major problem. The TLS certs are another layer of security though, sure.

My point is, thank you to the team for your concern, but some of us would just prefer to secure our vlan, firewalls, boxes, and then authenticate with the database via a user/password. We’re not being allowed to do that because we’re being told it’s not good for us. Let me decided what’s good for me. :slight_smile:

I mean all this w/ love, I love your product and team. Just wanted to give another perspective. I think a lot of people will have this perspective as your product becomes mainstream (and it should be mainstream, it’s amazing.)

PS: I for one wouldn’t mind setting up the clusters w/ TLS but allowing our application to connect and query the cluster w/ user/pass. That’s my main beef is having to include certs w/ my applications.

So your issue is mainly with the documentation, then? Because if you’re confident in the security of your network and trust everyone that has access to it, then you can go ahead and use the database in insecure mode connect as different users if you want. The users won’t have passwords, but we’re operating under the assumption that you trust everyone with access to your network so it should logically follow that passwords aren’t necessary.

The documentation is so strongly worded and passwords are disallowed because most people don’t realize the potential risks that @david outlined, and otherwise might believe that insecure mode is ok as long as passwords are used.

I have good news for you, then! All users other than root can authenticate with just a password in secure mode, if you so choose:


@a-robinson That’s new in v2.0, I didn’t know. Consider me a happy boy. :smile:

I was always approaching it from that standpoint. I wanted to deploy applications w/ basic auth. I wanted to share production and staging DB access to our team w/ non-root users w/ various permissions w/o having to make them fumble around w/ certs.

Good to know, thanks!

Thanks, nice to hear that securing does not impact the performance. Also the new v2.0 feature seems good - will look into that.