On a tangential note, I used to think the openssh developers was a little crazy for not using a (a subset of) x509 certs, but now, seeing how ssh is a part of go, I'm not sure if using ssh certs[1] for things like intra-server auth/authz might not be a good idea.
TLS is ok if you need to secure something that speaks HTTP (or IMAP etc) -- but I wonder if ssh certs might not be the lesser evil for something like what cockroachdb needs. Perhaps esepcially now as self-signed/"home grown" x509 certs are being relegated to the background by modern browsers -- so you'd end up needing a "real" cert for the status-server to present securely to a web-client, which might not match the wish for every node to have its own keypair.
https://www.cockroachlabs.com/docs/secure-a-cluster.html
(Much thanks to Go's extensive standard library: https://github.com/cockroachdb/cockroach/blob/master/securit... )
I've lost count on the number of projects that leaves "securing the server" as an exercise to the reader (about as useful as those error prompts that helpfully ask you to "contact the server administrator" (I AM THE ADMINISTRATOR!)).
I understand why not using TLS doesn't give an error, although I'd prefer it if it was more work to set up an insecure instance (eg: --force-no-tls --force-no-auth) -- but what cockroach does here is pretty good, and AFAIK best-in-class from those which it is natural to compare to (in all fairness, projects like postgresql a) doesn't do too bad, and b) have a lot of legacy cruft -- the old (current) assumption is of course that if you want TLS, you'll use your secure in-house CA for everything. Which even when running Microsoft AD is in my experience way too complex for most to bother with).
Another (bad) example here is openssh, that has had decent support for certificates rather than keys for a long while now, and yet I've yet to see anyone that appear to use ssh certs in anger (Myself included, it's high up on the infinite todo-list).
One other great example of making the best of what awful tools are available for securing communications is the Caddy web server, that comes with built-in support for letsencrypt: https://caddyserver.com/
That said, while I think the docs are pretty good here, a note that leaving an unecrypted, ca-key lying around is a bad idea, might be worth a mention even in the quick-setup. At least as it stands, it's reasonably easy for someone with a working knowledge of TLS/certificates to guess which parts should be secret (all the keys) and which parts should be kept air-gapped (the ca-key).
Maybe a link to how cockroach parses/verifies certs would be nice too, for those that do have a working internal CA -- along with a little info on how/if certs integrate with authenticating nodes (eg: will my printer.example.com x509-cert allow my hacked printer to join the cluster, if it is signed by the same CA?).
Despite all the comments, I'm really liking what I see so far -- I'll be keeping an eye on this project!