Secure your data by using a per-instance 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 per-instance CA. Memorystore for Redis Cluster provisions each cluster with its own, unique CA infrastructure. To access a cluster securely, you must configure your client application to trust this CA hierarchy. This involves downloading and installing CA certificates on each client that accesses the cluster.

Create a cluster that uses a per-instance CA

Console

Follow the steps at Create instances.

gcloud

To create a cluster that uses a per-instance 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-per-instance-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 per-instance CA, google-managed-per-instance-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-per-instance-ca

Download the CAs

If you enable in-transit encryption for a cluster, then when you use the get-cluster-certificate-authority command, the certificates of the CAs appear.

gcloud redis clusters get-cluster-certificate-authority CLUSTER_ID

Replace CLUSTER_ID with the ID of the cluster.

The response body includes certificates for all applicable CAs.

Install CA certificates on the client

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

To install a CA certificate 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 CAs and paste them into the server_ca.pem file.

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

Your file, as seen in the previous example, should use the following guidelines:

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

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. 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 certificates on the clients that access the cluster.

Installing the latest CA certificates periodically ensures that you have the necessary 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.