ObjectRocket Redis is now offering an additional level of security by providing the option of using SSL encryption between a customer’s client(s) and their ObjectRocket Redis instance(s). Customers will now have access to either a Public or ServiceNet connection string with or without SSL Encryption via the ObjectRocket control panel. This capability will give customers that want or need another layer of security the ability to encrypt traffic between their Redis client and the ObjectRocket Redis endpoint.
Redis and Security
As I stated in my previous blog on Redis and Security, Redis was not built with security in mind. It was designed to be performant and lightweight. Any time that you design something for performance, it is likely that you will have to make some sacrifices. There was some discussion at the Redis Developer’s Day in London last fall around adding security capabilities to Redis natively. We made the decision at that event to keep Redis biased towards performance as opposed to adding any overhead that would come with security improvements.
Why are we offering this now?
As Redis use cases grow more complex and more integral to an application’s architecture, customers want more security around their Redis instances and how they connect to them. Some customers also may simply have regulatory or compliance requirements that force them to look at their solution with security in mind. ObjectRocket Redis already requires customers to set an Access Control List (ACL) before their Redis instance is usable and password authentication every time that they connect to their Redis instance. ObjectRocket Redis also uses containerization to isolate each Redis instance and its associated resources such as the endpoints that the user connects to. Providing customers with the ability to use SSL encryption adds another layer of security all the way back to their client(s).
Availability
ObjectRocket Redis SSL Encryption will initially only be available on new ObjectRocket Redis instances. There are plans to migrate existing ObjectRocket Redis customers over to this capability without any customer impact. This should happen in the next few months following the initial release. If you are an existing ObjectRocket Redis customer and want to take advantage of the SSL encryption capability now, simply open a ticket with our support team to help get you migrated over to a new instance that has this capability. This capability will be available in all current Rackspace data centers where we offer ObjectRocket Redis; Virginia (IAD), Chicago (ORD), Dallas (DFW), and London (LON).
How does it work?
Customers will now be able to see SSL Encryption connection strings for both public and ServiceNet connections. This will be in addition to their standard or non SSL public and ServiceNet connection strings.
If they want to utilize these connection strings, they will simply need to change the connection string within their config file or code.
With the security philosophy in which Redis was designed, there are very few Redis clients that support SSL Encryption. Because of this, there likely are other steps that customers may need to take in order to get SSL Encryption setup correctly. Customers may need to use some type of SSL proxy in order to handle the SSL “handshake” that takes place between their client and the ObjectRocket Redis endpoint. An example of this would be stunnel. Once they have this in place, they just need to point the application to the desired SSL encryption connection string. There should be no additional code changes required on their end.
Again, depending upon how the customer is connecting to their ObjectRocket Redis instance(s) and the Redis client that they are using, customers may need to or want to download the certificate authority from Rackspace to verify the authenticity of the certificate that Rackspace is using during the “handshake” process. They can download the certificate authority here.
Limitations
The only limitation that exists for customers using the SSL Encryption connection string is a minimal impact to network latency. Several variables come into play when trying to test the impact: client type, client driver, network setup, etc. From our testing, expectations are that the latency will increase ~5%. Customers should always run some tests in advance of using SSL encryption in production to ensure that the performance is within their tolerance/expectations. As always, customers should reach out to us if they see any unexpected performance impact.
Beyond this, there should be no other feature limitations to a customer’s ObjectRocket Redis instance(s). We have designed this feature such that it does not limit other capabilities of ObjectRocket Redis.
Final Thoughts
Security will continue to be a hot topic in the Redis community. As Redis and Redis use cases evolve, we will need to make adjustments to ObjectRocket Redis to fit the needs that customers have. This feature is just another step in making sure that we make a managed Redis product that fits the needs of our growing customer base.
Additional Resources
- ObjectRocket Support (immediately opens a ticket with our support team)
- ObjectRocket Redis SSL Encryption Documentation
- Redis.io Security Documentation
- ObjectRocket Redis SSL Encryption Video Blog
- ObjectRocket Redis and Security Blog
