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.
The following are sample use cases for using in-transit encryption:
- Protect sensitive cached data: If you use Memorystore for Redis Cluster to store high-value information, such as session tokens, Personal Identifiable Information (PII), or API keys, then in-transit encryption prevents attackers with VPC access from accessing your data.
- Comply with industry standards: Many security frameworks, including HIPAA for healthcare and PCI DSS for financial data, mandate that sensitive information be encrypted both at rest and in transit for regulatory and industry compliance purposes.
- Secure Identity and Access Management (IAM) authentication: When you use IAM authentication to manage access to your data, Memorystore for Redis Cluster requires TLS to prevent the exposure or leaking of authentication tokens during transmission.
- Prevent person-in-the-middle attacks: TLS authenticates the server endpoint using Certificate Authorities (CAs). CAs protect your application against server spoofing and unauthorized data modification as the data moves between your application and Memorystore for Redis Cluster.
In-transit encryption prerequisites
To use in-transit encryption with Memorystore for Redis Cluster, you need the following:
A Redis client that supports TLS or a third-party TLS sidecar.
CA certificates that are installed on the client machine that accesses your cluster.
Built-in TLS was only supported for Redis, versions 6.0 and later. As a result, not every Redis client library supports TLS. If you use a client that doesn't support TLS, then we recommend using a third-party plugin that enables TLS for your client. You can see an example of how to connect to a cluster in Memorystore for Redis Cluster that has in-transit encryption enabled.
Certificate Authorities (CAs)
A cluster that uses in-transit encryption has Certificate Authorities (CAs) that authenticate the certificates of the machines in the cluster. Memorystore for Redis Cluster lets you choose a server CA mode. The CA mode determines which CA hierarchy is used to issue the digital certificates for a cluster.
Memorystore for Redis Cluster offers the following CA modes:
- 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 clients to trust this CA hierarchy. This involves downloading and installing CA certificates on each client that accesses the cluster.
- Shared CA: 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 clients need to manage. This CA mode is available in Preview.
- Customer-managed CA: use your own CA pool that's hosted on Certificate Authority Service. If your client applications are configured to trust this CA, then your applications can connect to a cluster without you having to download and install additional CA certificates. This gives you greater control and helps you meet compliance requirements. This CA mode is available in Preview.
Server certificate rotation
Every week, Memorystore for Redis Cluster conducts server-side certificate rotation for clusters that use the per-instance CA, shared CA, and customer-managed CA modes. New server certificates apply to new connections only, and existing connections remain alive during this rotation.
In addition to Memorystore for Redis Cluster conducting a weekly server-side certificate rotation, for the customer-managed CA mode, you can rotate the certificates on-demand.
Performance impact of enabling in-transit encryption
The in-transit encryption feature encrypts and decrypts data, which comes with a processing overhead. As a result, enabling in-transit encryption can reduce the performance of your clients. Also, when you use in-transit encryption, each additional connection comes with an associated resource cost.
To determine the latency associated with using in-transit encryption, compare the performance of your clients. To do this, benchmark the performance of a cluster that has in-transit encryption enabled against a cluster that has it deactivated.
Guidelines to improve performance
To improve the performance of a cluster, use the following guidelines:
When possible, decrease the number of client connections. Instead of creating on-demand, short-lived connections, establish and reuse long-running connections.
Increase the size of the cluster.
Increase the CPU resources of your client's host machine. Client machines with a higher CPU count yield better performance. If you use a Compute Engine VM, then we recommend that you use optimized clusters.
Decrease the payload size associated with the traffic of your client. Larger payloads require more round trips.