Redis Cache is an advanced key-value store that we should have all come across in one way or another by now. Azure, AWS and many other cloud providers have fully managed offerings for it, which is “THE” way we want to consume it. As a little bit of insight, Redis itself was designed for use within a trusted private network and does not support encrypted connections. Public offerings like Azure use TLS reverse proxies to overcome this limitation and provide security around the service.
However some Redis client libraries out there do not talk TLS. This becomes a problem when they are part of other tools that you want to compose your applications with.
Solution? We bring in something that can help us do protocol translation.
socat – Multipurpose relay (SOcket CAT)
Socat is a command line based utility that establishes two bidirectional byte streams and transfers data between them. Because the streams can be constructed from a large set of different types of data sinks and sources (see address types), and because lots of address options may be applied to the streams, socat can be used for many different purposes.
In short: it is a tool that can establish a communication between two points and manage protocol translation between them.
An interesting fact is that socat is currently used to port forward docker exec onto nodes in Kubernetes. It does this by creating a tunnel from the API server to Nodes.
Packaging socat into a Docker container
One of the great benefits of Docker is that it allows you to work in sandbox environments. These environments are then fully transportable and can eventually become part of your overall application.
The following procedure prepares a container that includes the socat binary and common certificate authorities required for public TLS certificate chain validation.
We first create our docker-socat/Dockerfile
Now we build a local Docker image by executing docker build -t socat-local docker-socat. You are free to push this image to a Docker Registry at this point.
Creating TLS tunnel into Azure Redis
To access Azure Redis you we need 2 things:
- The FQDN: XXXX-XXXX-XXXX.redis.cache.windows.net:6380
where all the X’s represent your dns name. - The access key, found under the Access Keys menu of your Cache instance. I will call it THE-XXXX-PASSWORD
Let’s start our socat tunnel by spinning up the container we just built an image for. Notice I am binding port 6379 to my Desktop so that I can connect to the tunnel from localhost:6379 on my machine.
Now let’s have a look at the arguments I am passing in to socat (which is automatically invoked thanks to the ENTRYPOINT ["socat"] instruction we included when building the container image).
- -v
For checking logs when when doingdocker logs socat - TCP-LISTEN:6379,fork,reuseaddr
– Start a socket listener on port 6379
– fork to allow for subsequent connections (otherwise a one off)
– reuseaddr to allow socat to restart and use the same port (in case a previous one is still held by the OS)
- openssl-connect:XXXX-XXXX-XXXX.redis.cache.windows.net:6380
– Create a TLS connect tunnel to the Azure Redis Cache.
Testing connectivity to Azure Redis
Now I will just test my tunnel using redis-cli which I can also use from a container. In this case THE-XXXX-PASSWORD is the Redis Access Key.
The thing to notice here is the--net host flag. This instructs Docker not to create a new virtual NIC and namespace to isolate the container network but instead use the Host’s (my desktop) interface. This means that localhost in the container is really localhost on my Desktop.
If everything is set up properly and outgoing connections on port6379 are allowed, you should get a PONG message back from redis.