A newer version of this documentation is available.

View Latest

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:

      1. 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
      2. 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
      3. 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.

      4. 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
      5. 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
      6. 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
      7. 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
      8. 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.