Network traffic between the individual nodes of a Couchbase-Server cluster can be encrypted, in order to optimize cluster-internal security.
Couchbase Server supports node-to-node encryption, whereby network traffic between the individual nodes of a cluster is encrypted, in order to optimize cluster-internal security.
Node-to-node encryption can be established on either of two levels:
Control. Cluster-management information passed between nodes by the Cluster Manager and related low-level processes is encrypted. However, the data that is passed between nodes by Couchbase Services continues to be passed in the clear. When node-to-node encryption is first enabled, this is the default.
All. Both cluster-management information and data is passed in encrypted form. Node-to-node encryption can be supported by means of either the Couchbase-provided certificates with which nodes are protected by default; or certificates installed by the administrator.
For practical steps towards set-up, see Manage Node-to-Node Encryption.
Node-to-node encryption is disabled by default. Note that auto-failover must be switched off both for a change to be made to the cluster’s address-family, and for encryption to be enabled or disabled: auto-failover can be switched back on after the necessary changes have been made. (This requirement prevents nodes that are undergoing changes from being determined unresponsive during the process, and unnecessarily failed over.)
Node-to-node encryption is managed by means of the Couchbase CLI. The typical command-sequence is summarized below.
Change address family. Both IPV4 and IPV6 addresses are supported: one or the other must be selected. The selected setting is applied to every node in the cluster. The address family is changed by means of the ip-family CLI command.
Enable cluster encryption. Cluster encryption must be specifically enabled: by default, it is disabled. To enable or disable cluster encryption, or to determine the current setting, use the node-to-node-encryption CLI command.
Establish cluster encryption-level. This determines whether only cluster-management information or both cluster-management information and data will be passed in encrypted form: these are respectively the control and all encryption levels. Use the setting-security CLI command to specify or to get the current setting.
If required, re-enable auto-failover.
For a more detailed account of this sequence, see Manage Node-to-Node Encryption.
Before the root or intermediate certificates for a cluster are either uploaded for the first time, or are subsequently rotated, node-to-node encryption should be disabled:
Use node-to-node-encryption, to disable node-to-node encryption. Note that node-to-node encryption cannot be disabled when the encryption-level has been specified as all. Before attempting to disable, determine the encryption-level, and if necessary, change it to control.
Re-enable node-to-node encryption, using node-to-node-encryption, and establish the appropriate level of encryption.
Note that the node certificates for a cluster can be created or rotated without node-to-node-encryption being disabled.