-
Notifications
You must be signed in to change notification settings - Fork 4.1k
server: clarify / improve the TLS join behavior for already-running, not-yet-initialized clusters #64934
Copy link
Copy link
Open
Labels
A-authenticationPertains to authn subsystemsPertains to authn subsystemsA-securityC-enhancementSolution expected to add code/behavior + preserve backward-compat (pg compat issues are exception)Solution expected to add code/behavior + preserve backward-compat (pg compat issues are exception)T-server-and-securityDB Server & SecurityDB Server & Security
Description
The new cockroach connect logic and underlying RPCs/APIs cover the following two use cases already:
-
the cluster is not yet running.
cockroach connect initcan set up certificates securely on every server where a node will be running. -
the cluster is already initialized.
cockroach connect joincan retrieve certificates securely from an already running node. The cluster must be already initialized because the join tokens are stored in a system table.
There is a gap here: what if the cluster is already running, but the cockroach init command has not run yet? With the current interfaces, we cannot add more nodes securely in this case.
There are two solutions for this:
- either tell the operator to shut down the non-initialized nodes, and re-run
connect initwith the new nodes - or, revisit the requirement that join tokens must be stored in a system table. Also make it possible to use "transient" (in-RAM only) join tokens on a specific node.
cc @aaron-crl @bdarnell for discussion
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
A-authenticationPertains to authn subsystemsPertains to authn subsystemsA-securityC-enhancementSolution expected to add code/behavior + preserve backward-compat (pg compat issues are exception)Solution expected to add code/behavior + preserve backward-compat (pg compat issues are exception)T-server-and-securityDB Server & SecurityDB Server & Security