Manage Node-to-Node Encryption

Network traffic between the individual nodes of a Couchbase-Server cluster can be encrypted, in order to optimize cluster-internal security.

Understanding Node-to-Node Encryption

Couchbase Server supports node-to-node encryption, whereby network traffic between the individual nodes of a cluster is encrypted.

Node-to-node encryption is managed by means of the Couchbase CLI. This page provides a sequence of calls, to exemplify how a cluster can be secured by means of node-to-node encryption. For a complete conceptual overview, see Node-to-Node Encryption.

Set Up Node-to-Node Encryption

The following sequence demonstrates how to set up node-to-node encryption for a cluster, using the Couchbase CLI. The sequence assumes:

The reader’s familiarity with the information provided at Node-to-Node Encryption.
A pre-existing cluster of two nodes, node1-devcluster.com and node2-devcluster.com, both running the latest version of Couchbase Server Enterprise Edition.
Node-to-node encryption initially disabled.
Auto-failover initially enabled.

Note that node-to-node encryption-enablement can also be performed when a cluster is being created. See Create a Cluster.

Proceed as follows:

Turn off auto-failover. Use the setting-autofailover CLI command, as follows
```
/opt/couchbase/bin/couchbase-cli setting-autofailover \
-c http://node1-devcluster.com:8091 \
-u Administrator \
-p password \
--enable-auto-failover 0
```
The value of 0 assigned to the --enable-auto-failover flag specifies that auto-failover be switched off. If the command is successful, the following output is displayed:
```
SUCCESS: Auto-failover settings modified
```

If you are using the Eventing Service and Eventing functions have been defined and deployed on the cluster, pause these functions. For information, see eventing-function-setup.

To find the set of deployed Eventing functions first list all Eventing functions and their state.

/opt/couchbase/bin/couchbase-cli eventing-function-setup \
-c http://node1-devcluster.com:8091 \
-u Administrator \
-p password \
--list

Below the output shows two Eventing functions with only the first one in the deployed state:

my_evt_function_a
 Status: deployed
 Source: metadata._default._default
 Metadata: source._default._default
my_evt_function_b
 Status: undeployed
 Source: metadata._default._default
 Metadata: source._default._default

The deployed Eventing function(s) above can be paused via the CLI

/opt/couchbase/bin/couchbase-cli eventing-function-setup \
-c http://node1-devcluster.com:8091 \
-u Administrator \
-p password \
--pause \
--name my_evt_function_a

Enable node-to-node encryption for the cluster. Use the node-to-node-encryption CLI command:
```
/opt/couchbase/bin/couchbase-cli node-to-node-encryption \
-c http://node1-devcluster.com:8091 \
-u Administrator \
-p password \
--enable
```
The --enable flag enables node-to-node encryption for the cluster, at the default level of control. If the command is successful, the following output is displayed:
```
Turned on encryption for node: http://node1-devcluster.com:8091
Turned on encryption for node: http://node2-devcluster.com:8091
SUCCESS: Switched cluster encryption on
```
The output indicates that encryption has been successfully enabled for each node in the cluster.
Establish an appropriate encryption-level for the cluster. This is achieved by the setting-security CLI command, specifying the --cluster-encryption-level parameter. Its value can be control, meaning that server-management information passed between nodes is passed in encrypted form; all, meaning that all information passed between nodes, including data handled by services, is passed in encrypted form; or strict, meaning all with only encrypted communication permitted between nodes and between the cluster and external clients. (Note, however, that after strict has been specified, communication that occurs entirely on a single node using the loopback interface — whereby the machine is identified as either localhost or 127.0.0.1 — is still permitted in non-encrypted form.)

For example:
```
/opt/couchbase/bin/couchbase-cli setting-security \
-c http://node1-devcluster.com:8091 \
-u Administrator \
-p password \
--set \
--cluster-encryption-level all
```
Passed as the value for the --cluster-encryption-level flag, all is specified as the new encryption-level for the cluster. If the command is successful, the following output is displayed:
```
SUCCESS: Security settings updated
```

If you are using the Eventing Service resume all previously paused Eventing functions (if any). For information, see eventing-function-setup.

/opt/couchbase/bin/couchbase-cli eventing-function-setup \
-c http://node1-devcluster.com:8091 \
-u Administrator \
-p password \
--resume \
--name my_evt_function_a

Switch auto-failover back on, using the setting-autofailover command:
```
/opt/couchbase/bin/couchbase-cli setting-autofailover \
-c node1-devcluster.com:8091 \
-u Administrator \
-p password \
--enable-auto-failover 1 \
--auto-failover-timeout 120 \
--enable-failover-of-server-groups 1 \
--max-failovers 2 \
--can-abort-rebalance 1
```
The parameter values specify that auto-failover be enabled with a timeout of 120 seconds; with a maximum of two, sequential automated failovers able to occur, prior to administrator intervention being required. Automated failover of server groups is enabled, as is the aborting of rebalance.

If the command succeeds, and the settings are successfully modified, the following output is displayed:
```
SUCCESS: Auto-failover settings modified
```

Confirm that node-to-node encryption is enabled, using the --get parameter to node-to-node-encryption:

/opt/couchbase/bin/couchbase-cli node-to-node-encryption \
-c http://node1-devcluster.com:8091 \
-u Administrator \
-p password \
--get

If the command is successful, the following output is displayed:

Node-to-node encryption is enabled

Confirm the established encryption-level, using the --get parameter to setting-security. Note that this call his here piped to the jq program, to optimize output-readability:
```
/opt/couchbase/bin/couchbase-cli setting-security \
-c http://node1-devcluster.com:8091 \
-u Administrator \
-p password \
--get | jq '.'
```
If successful, the command returns a JSON document that contains the current security settings for the cluster. The first part of the output may be as follows:
```
{
  "disableUIOverHttp": false,
  "disableUIOverHttps": false,
  "tlsMinVersion": "tlsv1",
  "cipherSuites": [],
  "honorCipherOrder": true,
  "clusterEncryptionLevel": "all",
  "data": {
    "supportedCipherSuites": [
      "TLS_AES_256_GCM_SHA384",
      "TLS_CHACHA20_POLY1305_SHA256",
      "TLS_AES_128_GCM_SHA256",
      "TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384",
            .
            .
            .
```
These contents include information on the cluster’s UI disablement settings, TLS minimum version, and ciper suites (listed per service). The output also contains the current encryption-level setting; which is here shown as all:

For information on UI disablement, see Manage Console Access.

This concludes the sequence of commands.