About in-transit encryption

This page gives an overview of in-transit encryption for Memorystore for Redis Cluster.

For instructions how to encrypt a connection with in-transit encryption, see Manage in-transit encryption.

Memorystore for Redis Cluster only supports TLS protocol versions 1.2 or higher.

Introduction

Memorystore for Redis Cluster supports encrypting all Redis traffic using the Transport Layer Security (TLS) protocol. When in-transit encryption is enabled Redis clients communicate exclusively across a secure connection. Redis clients that are not configured for TLS are blocked. If you choose to enable in-transit encryption you are responsible for ensuring that your Redis client is capable of using the TLS protocol.

Note: For instances with replicas, replicated data is fully encrypted at the network level based on Google Cloud encryption standards.

In-transit encryption prerequisites

In order to use in-transit encryption with Memorystore for Redis, you need:

1. A Redis client that supports TLS or a third-party TLS sidecar

2. Certificate Authorities installed on the client machine accessing your Redis instance

Native TLS was not supported prior to open source Redis version 6.0. As a result, not every Redis client library supports TLS. If you are using a client that does not support TLS, we recommend using the Stunnel third-party plugin that enables TLS for your client. See Securely connecting to a Redis instance using Stunnel and telnet for an example of how to connect to a Redis instance with Stunnel.

Certificate Authorities

A Redis cluster that uses in-transit encryption has unique Certificate Authorities (CAs) that are used to authenticate the certificates of the machines in your cluster. Each CA is identified by a certificate that you must download and install on the client accessing your Redis instance.

Note: CAs are valid for ten years from the date they are created. To ensure service continuity, new CAs must be installed on clients of the Redis instance before the previous CAs expire.

Certificate authority rotation

CAs are valid for 10 years upon instance creation. In addition, a new CA will become available prior to CA expiration.

Old CAs are valid until their expiration date. This gives you a window in which to download and install the new CA to clients connecting to the Redis instance. After the old CAs expires you can uninstall them from clients.

For instructions on rotating the CA, see Managing Certificate Authority rotation.

Server certificate rotation

Server-side certificate rotation occurs every week. New server certificates apply to new connections only, and existing connections remain alive during rotation.

Performance impact of enabling in-transit encryption

The in-transit encryption feature encrypts and decrypts data, which comes with processing overhead. As a result, enabling in-transit encryption can reduce performance. Also, when using in-transit encryption, each additional connection comes with as associated resource cost. To determine the latency associated with using in-transit encryption, compare application performance by benchmarking application performance with both a cluster that has in-transit encryption enabled and a cluster that has it disabled.

Guidelines for improving performance

• Decrease the number of client connections when possible. Establish and reuse long-running connections rather than creating on-demand short-lived connections.

• Increase the size of your Memorystore cluster.

• Increase the CPU resources of the Memorystore client host machine. Client machines with a higher CPU count yields better performance. If using a Compute Engine VM, we recommend compute optimized instances.

• Decrease the payload size associated with application traffic because larger payloads require more round trips.