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
andnode2-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 ofcontrol
. 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 becontrol
, 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; orstrict
, meaningall
with only encrypted communication permitted between nodes and between the cluster and external clients. (Note, however, that afterstrict
has been specified, communication that occurs entirely on a single node using the loopback interface — whereby the machine is identified as eitherlocalhost
or127.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 tonode-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 tosetting-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.