“Redis is a widely used high-performance database that is capable of storing a variety of data structures. Since it is used by large enterprise-level applications to provision caching, messaging systems, and database capacities, the security and data encryption aspects are equally important as the performance. Over the past decade, there has been an increasing trend in malicious attacks that have been triggered against databases to reveal sensitive information or to alter the data. So, the risk is the same with the applications that use Redis backends.
Redis is fundamentally designed for authorized connections within trustworthy environments. Hence, it is recommended not to expose the Redis database port to the general public or internet and untrusted networks. In most of the cases where web applications generate content by querying the Redis store and push data based on the client requests, it is mandatory to implement an intermediate layer to restrict or filter out client requests that are coming through the web applications. Redis provides a variety of encryption and security measures, such as access control lists(ACL), TLS support, and encryption at REST to protect data.”
Allow Trusted Traffic With Redis Authentication & ACL(Access Control Lists)
As mentioned, by design, Redis is not safe to expose to untrusted networks, internet, and client connections. If it is the case, Redis provides a database authentication mechanism where clients should authenticate using a username and password. Each user is associated with a limited set of functionalities, Redis keys, and commands. It would restrict certain clients by only having the permissions to execute read commands but not the write commands. Furthermore, ACL is used to restrict high-risk commands like FLUSHALL and FLUSHDB from untrusted sources. In addition, Redis has a variety of configuration commands introduced to manage the Redis instance in both the on-premise and cloud setups. These configuration commands are not very useful to consumers. So, ACL manages to hide those commands from the public as well.
Usually, the Redis config file contains a line called requirepass which can be used to enable password authentication for a given Redis database instance. With this option enabled, unauthenticated clients will not get access to the database at all. The AUTH command is used to authenticate users to the Redis databases. It is extended from Redis version 6, which can be used with two parameters as follows.
Inspecting the ACL for a Redis Instance
Redis ACLs can be inspected using the ACL LIST command, as shown in the following. Generally, it displays detailed information related to a user, such as a username, password status(required or not), access keys, commands, and pub/sub channels.
The above output can be interpreted as follows.
Different ACL rules are available to create correct users with minimum access levels to the Redis database instance. The ACL SETUSER command can be used to configure different users with different access levels.
Encrypt Transferred Data Using Redis TLS
From Redis version 6, SSL/TLS has been supported. It encrypts data sent over all the Redis communication channels such as client connections, cluster connections, sentinels and replication links. Furthermore, the Redis SSL/TLS needs to be enabled at compile time.
By default, Redis servers run in normal mode, which doesn’t support SSL/TLS encryption. Hence, you need to explicitly start the Redis instance in TLS mode, as shown in the following.
We assume that all the SSL certificates and keys are available. Similarly, to initiate a client connection, we should use the –tls flag along with necessary SSL keys and certificates as follows.
In addition, the Redis instance should be configured with an X.509 certificate and private key as well.
SSL/TLS Encryption in Replication, Sentinel, and Cluster Communication
In Redis, when the replication is enabled, the master instance uses the tls-port and tls-auth-clients options to let clients know the port that accepts TLS connections and whether client authentication is required or not. Similarly, in replica instances, it is recommended to use SSL/TLS encryption for outgoing connections towards master instances. In that case, the tls-replication option should be set to yes.
Whenever the Redis sentinel has been enabled for high availability needs, the tls-replication option decides on whether TLS or non-TLS connection has to be used when connecting to master servers. Similarly, the same directive governs the incoming connections from other sentinels are SSL/TLS enabled or not. If the tls-replication directive sets to yes, the tls-port option should be assigned with the appropriate port as well.
When the clusters are used in Redis, it is recommended to provide secure communication channels for cluster buses and cluster-cluster links. Redis provides the tls-cluster directive to determine the support for SSL/TLS encryption among cluster nodes. This directive should be set to yes when you need a TLS connection to send data from one node to another.
Encryption at REST
Redis is deployed in both the on-premise and cloud environments. In cloud deployments, the REST communication is always encrypted. The major cloud providers such as AWS, Azure, and GCP provision Redis deployments via encrypted channels. Furthermore, Amazon cloud provides in-transit encryption features that are listed below.
- Master-replica communication is encrypted in AWS deployed Redis instances.
- SSL enabled server and client connections
- Client and server authentications support using the Redis AUTH command discussed in an earlier section.
In summary, Redis is not designed to expose its TCP port to untrusted client connections in unreliable environments. By design, it has been developed only for trusted sources. As mentioned, in the case of Redis exposed to the public via a web application, an additional security layer has to be implemented between the client connections and the Redis instance. According to this article, Redis supports access control lists(ACLs), TLS support, and Encryption at REST to mitigate malicious attacks. In addition, we have discussed the SSL/TLS support for the Redis cluster, replica, and sentinel communication as well. Overall, it is recommended to practice the above techniques whenever the Redis instance is exposed to the public.