Movatterモバイル変換

Once you have created a CA and certificate, you can test the availability of the TLS connection to the management server by running thendb_mgm client with--test-tls, like this:

$> ndb_mgm --test-tlsNo valid certificate.

An appropriate message is generated if the client can connect using TLS. You may need to include otherndb_mgm options such as--ndb-tls-search-path to facilitate the TLS connection, as shown here:

$> ndb_mgm --test-tls --ndb-tls-search-path="CA:keys"Connected to management server at localhost port 1186 (using TLS)

If the client connects without using TLS, this is also indicated, similarly to what is shown here:

$> ndb_mgmConnected to management server at localhost port 1186 (using cleartext)$>

You can cause the cluster to use the CA and certificates created withndb_sign_keys by performing a rolling restart of the cluster, beginning with the management nodes, which should be restarted using the--ndb-tls-search-path option. After this, restart the data nodes, again using--ndb-tls-search-path.--ndb-tls-search-path is also supported formysqld run as a cluster API node.

For TLS to function, every node connecting to the cluster must have a valid certificate and key. This includes data nodes, API nodes, and utility programs. The same certificate and key files can be used by more than one node.

Data nodes log the TLS connection and include the full path to the certificate file used, as shown here:

$> ndbmtd -c localhost:1186 --ndb-tls-search-path='CA:keys'2023-12-19 12:02:15 [ndbd] INFO     -- NDB TLS 1.3 available using certificate file 'keys/ndb-data-node-cert'2023-12-19 12:02:15 [ndbd] INFO     -- Angel connected to 'localhost:1186'2023-12-19 12:02:15 [ndbd] INFO     -- Angel allocated nodeid: 5

You can verify that cluster nodes are using TLS to connect by checking the output of theTLS INFO command in thendb_mgm client, like this:

$> ndb_mgm --ndb-tls-search-path="CA:keys"-- NDB Cluster -- Management Client --ndb_mgm> TLS INFOConnected to management server at localhost port 1186 (using TLS) Main interactive connection is using TLSEvent listener connection is using TLS Server reports 6 TLS connections.  Session ID:          32  Peer address:        ::  Certificate name:    NDB Node Dec 2023  Certificate serial:  39:1E:4A:78:E5:93:45:09:FC:56  Certificate expires: 21-Apr-2024   Session ID:          31  Peer address:        127.0.0.1  Certificate name:    NDB Node Dec 2023  Certificate serial:  39:1E:4A:78:E5:93:45:09:FC:56  Certificate expires: 21-Apr-2024   Session ID:          30  Peer address:        127.0.0.1  Certificate name:    NDB Node Dec 2023  Certificate serial:  39:1E:4A:78:E5:93:45:09:FC:56  Certificate expires: 21-Apr-2024   Session ID:          18  Peer address:        127.0.0.1  Certificate name:    NDB Data Node Dec 2023  Certificate serial:  57:5E:58:70:7C:49:B3:74:1A:99  Certificate expires: 07-May-2024   Session ID:          12  Peer address:        127.0.0.1  Certificate name:    NDB Data Node Dec 2023  Certificate serial:  57:5E:58:70:7C:49:B3:74:1A:99  Certificate expires: 07-May-2024   Session ID:          1  Peer address:        127.0.0.1  Certificate name:    NDB Management Node Dec 2023  Certificate serial:  32:10:44:3C:F4:7D:73:40:97:41  Certificate expires: 17-May-2024      Server statistics since restart  Total accepted connections:        32  Total connections upgraded to TLS: 8  Current connections:               6  Current connections using TLS:     6  Authorization failures:            0ndb_mgm>

IfCurrent connections andCurrent connections using TLS are the same, this means that all cluster connections are using TLS.

Once you have established TLS connections for all nodes, you should make TLS a strict requirement. For clients, you can do this by settingndb-mgm-tls=strict in themy.cnf file on each cluster host. Enforce the TLS requirement on the management server by settingRequireTls=true in the[mgm default] section of the clusterconfig.ini file, then performing a rolling restart of the cluster so that this change takes effect. Do this for the data nodes as well, by settingRequireTls=true in the[ndbd default] section of the configuration file; after this, perform a second rolling restart of the cluster to make the changes take effect on the data nodes. Startndb_mgmd with the--reload and--config-file options both times to ensure that each of the two configuration file changes is read by the management server.

To replace a private key, usendb_sign_keys--create-key to create the new key and certificate, with the--node-id and--node-type options if and as necessary to limit the replacement to a single node ID, node type, or both. If the tool finds existing key and certificate files, it renames them to reflect their retired status, and saves the newly created key and certificate as active files; the new files are used the next time that the node is restarted.

To replace a certificate without replacing the private key, usendb_sign_keys without supplying the--create-key option. This creates a new certificate for the existing key (without replacing the key), and retires the old certificate.

Remote key siging is is also supported by ndb_sign_keys. Using SSH, the--remote-CA-host option supplies the SSH address of the CA host inuser@host format. By default, the localndb_sign_keys process uses the systemssh utility and address to runndb_sign_keys on the remote host with the correct options to perform the desired signing. Alternately, if--remote-openssl=true,openssl rather thanndb_sign_keys is used on the remote host.

When using remote signing, the data sent over the network is a PKCS#10 signing request, and not the private key, which never leaves the local host.