Secure your data by using a shared Certificate Authority (CA)

You can encrypt all data that moves between your client applications and Memorystore for Redis Cluster securely. This is in-transit encryption. By using in-transit encryption, all Redis traffic is encrypted through the Transport Layer Security (TLS) protocol. This ensures that all data that moves between your applications and Memorystore for Redis Cluster remains confidential and untampered.

When in-transit encryption is enabled, Redis clients communicate exclusively across a secure connection. Redis clients that aren't configured for TLS are blocked. If you choose to use in-transit encryption, then you're responsible for ensuring that your Redis client can use the TLS protocol.

Clusters that use in-transit encryption have Certificate Authorities (CAs). You use the CAs to authenticate the certificates of the machines in your clusters.

One CA mode that you can use is a shared CA. A shared CA is a managed, regionalized CA infrastructure. For each region, you can download a single CA certificate bundle. This bundle is valid for all clusters located in a region that you configure to use the shared CA. Using a shared CA reduces the number of certificates that your clients need to manage.

Create a cluster that uses a shared CA

Console

Follow the steps at Create instances.

gcloud

To create a cluster that uses a shared CA, use the gcloud redis clusters create command.

gcloud redis clusters create CLUSTER_ID \
--region=REGION_ID \
--network=NETWORK \
--replica-count=REPLICA_COUNT \
--node-type=NODE_TYPE \
--shard-count=SHARD_COUNT \
--transit-encryption-mode=server-authentication \
--server-ca-mode=google-managed-shared-ca

Make the following replacements:

CLUSTER_ID: the ID of the cluster that you're creating. The cluster ID must be 1 to 63 characters, and use only lowercase letters, numbers, or hyphens. It must start with a lowercase letter, and end with a lowercase letter or number.
REGION_ID: the region where you want the cluster to be located.
NETWORK: the network that you use to create the cluster. It must use this format: projects/NETWORK_PROJECT_ID/global/networks/NETWORK_ID. The network ID that you use must match the network ID that the service connection policy uses. Otherwise, you can't create the cluster.
REPLICA_COUNT: the number of replicas (per shard). Accepted values are 0-5.
NODE_TYPE: the node type. Accepted values are:
- redis-shared-core-nano
- redis-standard-small
- redis-highmem-medium
- redis-highmem-xlarge
Caution: We recommend that you use the redis-shared-core-nano node type for development or testing purposes only because this node type has no SLA. If you run Memorystore for Redis Cluster in a production environment, then we recommend using the redis-standard-small, redis-highmem-medium, or redis-highmem-xlarge node types. For more information about these node types, see Choose a node type.
SHARD_COUNT: the number of shards in the cluster. The shard count determines the total memory capacity for storing cluster data. For more information about cluster specifications, see Cluster and node specification.

The server-ca-mode parameter represents the CA mode for the cluster. For a shared CA, google-managed-shared-ca is the value for the parameter. If you don't use this parameter, then the default CA mode is per-instance.

For example:

gcloud redis clusters create my-cluster \
--region=us-central1 \
--network=projects/my-network-project/global/networks/default \
--replica-count=1 \
--node-type=redis-highmem-medium \
--shard-count=3 \
--transit-encryption-mode=server-authentication \
--server-ca-mode=google-managed-shared-ca

Download the CA certificate bundle

To view the CA certificate bundle and install the CA certificates onto your client application, use the get-shared-regional-certificate-authority command.

gcloud redis clusters get-shared-regional-certificate-authority
--region=REGION_ID

Replace REGION_ID with the region where the cluster is located.

Download regional CA certificate bundles for a shared CA

You can use the following table to download the regional CA certificate bundles.

Region name	Location	Certificate bundle
Global	All locations	global.pem
`africa-south1`	Johannesburg	africa-south1.pem
`asia-east1`	Taiwan	asia-east1.pem
`asia-east2`	Hong Kong	asia-east2.pem
`asia-northeast1`	Tokyo	asia-northeast1.pem
`asia-northeast2`	Osaka	asia-northeast2.pem
`asia-northeast3`	Seoul	asia-northeast3.pem
`asia-south1`	Mumbai	asia-south1.pem
`asia-south2`	Delhi	asia-south2.pem
`asia-southeast1`	Singapore	asia-southeast1.pem
`asia-southeast2`	Jakarta	asia-southeast2.pem
`australia-southeast1`	Sydney	australia-southeast1.pem
`australia-southeast2`	Melbourne	australia-southeast2.pem
`europe-central2`	Warsaw	europe-central2.pem
`europe-north1`	Finland	europe-north1.pem
`europe-north2`	Stockholm	europe-north2.pem
`europe-southwest1`	Madrid	europe-southwest1.pem
`europe-west1`	Belgium	europe-west1.pem
`europe-west2`	London	europe-west2.pem
`europe-west3`	Frankfurt	europe-west3.pem
`europe-west4`	Netherlands	europe-west4.pem
`europe-west6`	Zurich	europe-west6.pem
`europe-west8`	Milan	europe-west8.pem
`europe-west9`	Paris	europe-west9.pem
`europe-west10`	Berlin	europe-west10.pem
`europe-west12`	Turin	europe-west12.pem
`me-central1`	Doha	me-central1.pem
`me-central2`	Dammam	me-central2.pem
`me-west1`	Tel Aviv	me-west1.pem
`northamerica-northeast1`	Montréal	northamerica-northeast1.pem
`northamerica-northeast2`	Toronto	northamerica-northeast2.pem
`northamerica-south1`	Mexico	northamerica-south1.pem
`southamerica-east1`	São Paulo	southamerica-east1.pem
`southamerica-west1`	Santiago	southamerica-west1.pem
`us-central1`	Iowa	us-central1.pem
`us-east1`	South Carolina	us-east1.pem
`us-east4`	Northern Virginia	us-east4.pem
`us-east5`	Columbus	us-east5.pem
`us-south1`	Dallas	us-south1.pem
`us-west1`	Oregon	us-west1.pem
`us-west2`	Los Angeles	us-west2.pem
`us-west3`	Salt Lake City	us-west3.pem
`us-west4`	Las Vegas	us-west4.pem

Install the CA certificate bundle on the client

You must install the CA certificate bundle on the client that connects to the cluster. Depending on the type of client, the CA certificate installation might vary.

To install a bundle on a Compute Engine Linux VM, do the following:

Use SSH to connect to a Compute Engine Linux client.
In the client, use the following command to create a server_ca.pem file:
```
sudo vim /tmp/server_ca.pem
```

Download the CA certificate bundle and paste the certificates into the server_ca.pem file.

You must format the text of the CAs correctly. The server_ca.pem file might appear, as follows:

To format the text in the file correctly, use the following guidelines:

Copy the entire CA certificate bundle, including the -----BEGIN CERTIFICATE----- and -----END CERTIFICATE----- lines.
Make sure that the text of the certificates is completely left justified. Verify that no spaces appear in front of any line of the certificates.
Add each CA certificate on a new line. Verify that no blank lines exist between certificates.

Configure the client for in-transit encryption

The client that you use to connect to the cluster must either support TLS or use a third-party sidecar to enable TLS.

If your client supports TLS, then configure it to point to the cluster's IP address, port 6379, and the file containing the CA certificate bundle. You can see an example of how to connect to a cluster that has in-transit encryption enabled.

Manage the CA rotation

We recommend that you install all downloadable CA certificate bundles on the clients that access the cluster.

Installing the latest CA certificate bundles periodically ensures that you have the necessary CA certificates when Memorystore for Redis Cluster rotates the CAs. During this rotation, both the existing CAs and new CAs are active.

Code sample to connect to a cluster that uses in-transit encryption

To view a code sample on how to set up a client library to connect to a cluster that uses in-transit encryption, see In-transit encryption client library code sample.