“In general, Redis is not optimized for maximum security but for maximum performance and simplicity.” This statement is taken directly from the Redis.io documentation on Redis and Security. Understanding this first and foremost helps set the stage for a discussion on ObjectRocket Redis functionality as it relates to security.
Connectivity
With ObjectRocket Redis being a managed Redis solution that we host on Rackspace hardware, customers have to connect to that hardware. The Redis.io documentation states that “Redis is designed to be accessed by trusted clients inside trusted environments.” This means that usually it is not a good idea to expose the Redis instance directly to the internet or, in general, to an environment where untrusted clients can directly access the Redis TCP port or UNIX socket.
When an ObjectRocket Redis customer creates a new instance, they are given both a public connection string and a ServiceNet connection string. For a Rackspace customer, we recommend that they use the ServiceNet connection string for both security and performance reasons. From a security perspective, it adheres the closest to the Redis.io position of “not being exposed directly to the internet.” This routes their traffic only on ServiceNet and is not available to the internet at large.
For an AWS hosted customer, they can use the public connection string and still adhere to not being exposed directly to the internet. ObjectRocket employs AWS Direct Connect for AWS customers connecting to ObjectRocket Redis. AWS DirectConnect acts as a private connection between their AWS hardware and their ObjectRocket Redis instance. This is done behind the scenes and the customer doesn’t have to do anything different. This functionality only applies to the IAD (East Coast) data center for the time being.
Customers can use the public connection string to connect to their ObjectRocket Redis instance and still be confident that their data is secure due to the additional security features that are included in the ObjectRocket Redis offering. They just need to be aware that their data is traveling via the internet and could be exposed.
Once a customer determines the best network solution for their implementation of Redis, there are additional security measures that Redis supports.
Network Access Controls
The Redis.io documentation states that “Access to the Redis port should be denied to everybody but trusted clients in the network, so the servers running Redis should be directly accessible only by the computers implementing the application using Redis.” ObjectRocket requires customers set an Access Control List (ACL) before their Redis instance is usable. This is done by the user through the UI after the instance is created. We recommend that the customer only add the IPs or IP ranges of the client machines which will need access to the instance. Anything not added in will not be accepted by the endpoint of their Redis instance.
Authentication
Redis itself provides a layer of authentication that ObjectRocket requires and provides by default. When a customer creates their ObjectRocket Redis instance, they are provided with a password. This password is long and complex enough to prevent brute force attacks. With this authentication in place, Redis will refuse any query by unauthenticated clients. A client authenticates itself by sending the AUTH command followed by the password.
Process Isolation
While each ObjectRocket Redis setup runs on shared hardware, we utilize standard Linux containerization capabilities to isolate each Redis instance and it’s associated resources such as the endpoints that the user connects to. Customers thus also do not have access to the containers or the hosts involved with their resources. They can’t even talk directly to Sentinel. This process isolation is just another step that we take to protect ObjectRocket Redis customers.
Data Encryption
The Redis.io documentation states that “Redis does not support encryption. In order to implement setups where trusted parties can access a Redis instance over the internet or other untrusted networks, an additional layer of protection should be implemented, such as an SSL proxy.” The encryption that is described here is network encryption. It does not apply to “data at rest”. Some providers will provide instructions on how to setup Stunnel to tunnel Redis traffic through an SSL connection. Stunnel has issues and requires a mechanism which would break the container based isolation that ObjectRocket Redis employs. That said, data encryption is something that we see as an important feature for some customers. It is on our roadmap of future feature enhancements for early next year.
PCI Compliance
Sometimes, customers or potential customers will express an interest in using Redis in a PCI Compliant environment. This makes for a difficult conversation given how Redis is designed. There is no Redis solution in the market that will qualify for PCI compliance and still be called Redis. Just the general “one account gets everything” nature and the lack of audit trail capability would limit a true Redis solution from being PCI compliant. More specific examples limiting this are account limitation and access, the plain text protocol, the plain text in-memory storage, the plain-text disk storage, the use of plain-text password configuration in the config, etc. Without forking Redis and re-writing major chunks of it, we could not provide a PCI compliant solution. This would defeat the purpose of us providing a managed Redis solution and being part of what we believe makes Redis great – the open-source community.
Conclusion
There is always a price to be paid when you make simplicity and performance the main priorities. In the case of Redis, one of the sacrifices is security. This does not make Redis a completely un-securable solution. Rather, if security is the top priority, Redis is probably not the best solution.
