Managing XDCR Data Encryption

reference

XDCR data encryption provides SSL encryption for data replication. Enterprise Edition only.

Description

The process for configuring XDCR with data encryption involves configuring the XDCR cluster reference with data encryption enabled, providing the SSL certificate, and configuring replication.

HTTP method and URI

The following summarizes the HTTP methods used for defining XDCR data encryption:

HTTP method URI path Description

HTTP method	URI path	Description
GET	`/pools/default/remoteClusters`	Gets the destination cluster reference
POST	`/pools/default/remoteClusters`	Creates a reference to the destination cluster
POST	`/pools/default/remoteClusters/[Name]`	Modifies the destination cluster reference
DELETE	`/pools/default/remoteClusters/[Name]`	Deletes the reference to the destination cluster.

GET

/pools/default/remoteClusters

Gets the destination cluster reference

POST

/pools/default/remoteClusters

Creates a reference to the destination cluster

POST

/pools/default/remoteClusters/[Name]

Modifies the destination cluster reference

DELETE

/pools/default/remoteClusters/[Name]

Deletes the reference to the destination cluster.

Retrieving certificates

To retrieve the SSL certificate from the destination cluster to the source cluster use the following HTTP method and URI:

HTTP method and URI

GET /pools/default/certificate

Syntax

curl http://[remoteHost]:[port]/pools/default/certificate

Example

curl http://remoteHost:8091/pools/default/certificate > ./remoteCert.pem

Regenerating certificates

To regenerate a certificate on a destination cluster, use the following HTTP method and URI:

HTTP method and URI

POST /controller/regenerateCertificate

Example

curl -X POST http://Administrator:asdasd@remoteHost:8091/controller/regenerateCertificate

Configuring XDCR with data encryption

A POST to /pools/default/remoteClusters creates the XDCR cluster reference from the source cluster to the destination cluster. The secureType parameter can be:

none: The connection is not secured.
half: Only the password is encrypted. If the destination cluster is running Couchbase Enterprise Server version 5.5 or later, SCRAM SHA is used, and no certificate is required. If the destination cluster is running a pre-5.5 version of Couchbase Enterprise Server, TLS is used, and the root certificate of the destination cluster must be provided. In both cases, the username and password of the destination cluster’s Full, Cluster, or XDCR Administrator must be provided. If specified, the root certificate of the destination cluster is ignored if the destination cluster is running a pre-5.5 version of Couchbase Enterprise Edition.

Before using SCRAM SHA in a half-secure replication, see the important information provided in SCRAM SHA and XDCR.
full: Both password and data are encrypted. TLS is used. This requires either:
- The username and password of the destination cluster’s Full, Cluster, or XDCR Administrator; plus the root certificate of the destination cluster.
- The root certificate of the destination cluster; plus the client certificate and client private key of the local cluster.

HTTP method and URI

The following HTTP method and URI modifies the destination cluster reference.

POST /pools/default/remoteClusters

Syntax

curl -X POST  -u Admin:myPassword
  http://localHost:port/pools/default/remoteClusters
  -d name=<clusterName>             // Remote cluster name
  -d hostname=<host>:<port>       // FQDN of the remote host.
  -d username=<adminName>           // Remote cluster Admin name
  -d password=<adminPassword>       // Remote cluster Admin password
  -d demandEncryption=[true|false]  // Required to be true for either half or full encryption
  -d encryptionType=["half"|"full"] --data-urlencode "certificate=$(cat remoteCert.pem)"
 // set to "half" to just encrypt log-in details

Example 1

This secures password and data, by means of TLS.

curl -u Administrator:password -v -X POST http://10.142.180.1:8091/pools/default/remoteClusters
-d 'name=remoteName' \
-d 'hostname=10.142.180.101:8091' \
-d 'username=remoteAdministrator' \
-d 'password=remotePassword' \
-d 'demandEncryption'=true \
-d 'encryptionType=full' \
--data-urlencode "certificate=$(cat ./cert/remoteClusterRootCert.pem)"

Example 2

This secures both authentication and data, by means of TLS; using root and client certificates, and client private key.

curl -X POST -u Administrator:welcome \
http://127.0.0.1:9000/pools/default/remoteClusters \
-d name=rem \
-d hostname=127.0.0.1:9001 \
-d 'demandEncryption'=true \
-d secureType=full \
--data-urlencode "certificate=$(cat /Users/yu/cert/root/ca.pem)" \
--data-urlencode "clientCertificate=$(cat /Users/yu/pem/chain.pem)" \
--data-urlencode "clientKey=$(cat /Users/yu/cert/client/client/client.key)"

Example 3

This secures password only, by means of SCRAM-SHA.

curl -u Administrator:password -v -X POST http://10.142.180.1:8091/pools/default/remoteClusters \
-d 'name=remoteName' \
-d 'hostname=10.142.180.101:8091' \
-d 'username=remoteAdministrator' \
-d 'password=remotePassword' \
-d 'demandEncryption'=true \
-d 'secureType=half'

The response obtained from successfully securing the password with SCRAM-SHA is as follows:

{
"deleted": false,
"demandEncryption": true,
"encryptionType": "half",
"hostname": "10.142.180.101:8091",
"name": "remoteName",
"secureType": "half",
"uri": "/pools/default/remoteClusters/remoteName",
"username": "remoteAdministrator",
"uuid": "9b323738eb48104a72d15e7230911358",
"validateURI": "/pools/default/remoteClusters/remoteName?just_validate=1"
}

Disabling data encryption

To modify the XDCR configuration so that SSL data encryption is disabled, execute a POST from the source cluster to the destination cluster with demandEncryption=0.

HTTP method and URI

POST /pools/default/remoteClusters

Example

curl -X POST  -u myAdmin:myPassword
  http://192.168.0.1:8091/pools/default/remoteClusters/ \
  -d 'name=remoteName' \
  -d 'hostname=10.3.4.187:8091'\
  -d 'username=remoteAdmin' -d 'password=remotePassword' \
  -d 'demandEncryption=0'