Problem:

Managing certificates by manually moving files on nodes is slow, frustrating, and error-prone. There is a major difference in effort involved between a secure cluster and an insecure cluster because of this.

• Forcing an insecure cluster to have no security at all instead of at least allowing a root user password is hostile to users and basically offers no choice.
• Certificates are tied to DNS/name entries, but these can be dynamic or otherwise not match the underlying CRDB node name which creates a source of identity conflict.
• Command line setup is much easier to automate compared to deploying files, especially when certificates are unique to each node.
• Using other tools like Ansible, Chef or Kubernetes can help but increase complexity and dependencies.
• Some environments already have other security features and use encrypted traffic, so CRDB encryption is an unnecessary addition.

Solutions:

• Allow setting a password for insecure clusters for users who want to operate with that level of security.
• Separate traffic encryption from host authentication, by allowing nodes to join a cluster via a short-lived token, or disable hostname authentication completely and instead rely on the fact that nodes are deployed with the same certs and can't communicate otherwise, implying they are right nodes.

Epic: CRDB-6663

Jira issue: CRDB-6351