[bdarnell]

What "standard auth options" do you have in mind for node-to-node auth? The ones that come to my mind are even more of a pain to set up than TLS certs.

It's true that setting up a secure cluster is kind of annoying right now. But the kubernetes templates (https://github.com/cockroachdb/cockroach/tree/master/cloud/k...) do support secure mode now, and the plan is to provide more like this so it's not something that everyone has to solve by hand.

If you know or can predict the addresses or hostnames you'll be using, then it's possible to generate one cert and reuse it for multiple nodes. This isn't ideal from a security perspective since you lose the ability to revoke individual certs, but since we don't (yet) support CRLs/OCSP it's not much of a loss.

Adding an option to skip hostname checks for node certs might make this less of a pain (it would then be trivial to share one cert for all nodes if that's what you want to do). We'll consider that and see if it compromises any important security properties.

[manigandham]

Ah, didn't see that on the K8S docs page which only lists insecure mode... but this secure mode requires manual intervention to approve the certificates, which is the antithesis of easy automated scaling and availability.

Hostname checks make sense for websites since useragents cant trust anything but I don't see the advantage for managing a db cluster. When would you need to revoke an individual cert and why wouldn't that be better handled by just shutting down the VM or container instead?

I'd prefer nodes using self-signed certs to securely connect, then user/pass or other secret to authenticate to cluster - but yes, if you remove the hostname check then the shared certs can do double duty as encryption/auth to the cluster, although this now brings up maintenance issues with rolling certs. Either way passing secrets (password or cert file) is easy when it's the same across the cluster.

It seems like CRDB could easily run in a simple replicaset with no maintenance but that requires running insecure, or have a rather convoluted manual process. Something in the middle would be much better.

[bdarnell]

> When would you need to revoke an individual cert and why wouldn't that be better handled by just shutting down the VM or container instead?

You revoke a cert when it's somehow been compromised and something other than the VM/container that's supposed to has it gets a copy of it.

[manigandham]

I cant see how that cert would be lost where the node/container hasn't already been compromised. At that point there is a critical security issue where revoking a single certificate doesn't seem to cover much since the entire cluster should be reviewed and secured again with new keys.

Either way, I'd much prefer to make that decision as the admin rather than be forced into either extreme. Removing hostnames and having an easy way to roll certificates would go far towards operational simplicity and security.

[smarterclayton]

Hopefully in the next few releases Kubernetes as well will be able to give pods unique cryptographic identities that can make securing individual nodes even easier.

Projects like cockroachdb are one of the key use cases we keep in mind when we look at how Kubernetes can evolve to make apps more secure by default.