Automating Redis TLS certificate management with Smallstep

Carl-Tashian.jpg

Carl Tashian

Follow Smallstep

On the Smallstep platform, we're excited to add automated certificate management tailored to specific workload types like NGINX, MySQL, and Redis.

Our product is evolving very quickly, so we're using this chance to show off some of the work we've done to make it easier to manage encryption on your workloads.

In this tutorial, we'll install Smallstep on an Ubuntu/Debian Linux VM, and use it to manage the server TLS certificate for a Redis server.

We also have a video walkthrough of this post available.

Before you begin

Getting Started

Redis doesn't ship with TLS certificates enabled. We're going to enable server TLS in Redis, using Smallstep to manage and renew the server certificate.

First, in your Smallstep Dashboard, in the Workloads tab, create a Redis workload collection. Associate the collection with the Device collection you created above.

Be sure to configure the certificate file ownership to user redis and group redis. You can find this in the advanced setting when you configure the Redis workload.

Configure your Redis server to use certificates

The following configuration file will set up Redis to use your Smallstep PKI.

port 0
tls-port 6379
tls-cluster yes
tls-replication yes

tls-cert-file /path/to/step-agent/workload/service.crt
tls-key-file /path/to/step-agent/workload/service.key

tls-ca-cert-file /path/to/step-agent/redis/root_ca.crt

tls-protocols "TLSv1.2 TLSv1.3"
tls-ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-CHACHA20-POLY1305
tls-ciphersuites TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256
tls-prefer-server-ciphers no

You'll need to change the values of tls-cert-file, tls-key-file, and tls-ca-cert-file to match the configuration on your system. To find the correct paths for these files, run sudo step agent config on your VM. As long as you've added a Redis workload and have associated it with your VM, this command will print out your agent's configuration, including all workload-specific parameters.

Now reload Redis’s configuration:

systemctl restart redis.service

Your Redis TLS certificate is now being continuously monitored and managed by Smallstep.

Confirmation

To connect to your Redis workload, the Certificate Authority's root certificate must be downloaded and trusted in your clients.

Configure a Client to Use Redis

To securely connect Redis with end-to-end encryption, clients must be configured to use TLS, and to trust certificates signed by your Smallstep CA. You will need to add your CA’s root certificate to the system trust store on client devices.

First, download your CA root. You'll need your team name. It's the path segment after /app in the URL you use to access the Smallstep dashboard:

step ca bootstrap --team [your-team-name] --team-authority workloads --install

The --install flag is optional. It will install the root CA certificate in your system trust store.

Output:

The root certificate has been saved in /home/carl/.step/authorities/smallstep/certs/root_ca.crt.
The authority configuration has been saved in /home/carl/.step/authorities/smallstep/config/defaults.json.
The profile configuration has been saved in /home/carl/.step/profiles/smallstep/config/defaults.json.

Then, send a PING command to Redis to test your TLS configuration:

$ redis-cli --tls --cacert /path/to/root_ca.crt ping

Output:

PONG

Your Redis server connections are now encrypted with TLS.

Moving Into Production

How you operationalize Smallstep is going to depend on your deployment method and context.

For Redis workloads

Ansible cookbooks and a Terraform provider will be ready very soon. In the meantime, the Smallstep API will let you scale and automate much of the process described in this tutorial.

For Redis clients

Rather than manually running the step ca bootstrap command for each machine that needs to trust your CA, most teams will use some form of automation to distribute the root certificate. Depending on your deployment method and contexts, this may be a configuration management tool (like Ansible or Puppet), a Mobile Device Management (MDM) solution, or something else. Some examples:

  • Use Ansible to add root_ca.crt directly to the ca-ceritficates bundle on linux VMs so running applications trust the API servers they call
  • Bake root_ca.crt directly into base Docker images for gRPC so gRPC clients can always reference the trusted CA
  • Store root_ca.crt in a Kubernetes Secret and inject it into an environment variable for access from application code
  • Use Jamf to install root_ca.crt in the trust stores of every employee Macbook so their web browsers trust internal websites
  • Use Puppet to run step ca bootstrap with --install on target machines that you want to implicity trust the CA
  • Store ca.crt in a Kubernetes ConfigMap and mount it to pods for reference on the filesystem

Sources

Redis TLS Documentation.
Redis Configuration Documentation.

Carl Tashian (Website, LinkedIn) is an engineer, writer, exec coach, and startup all-rounder. He's currently an Offroad Engineer at Smallstep. He co-founded and built the engineering team at Trove, and he wrote the code that opens your Zipcar. He lives in San Francisco with his wife Siobhan and he loves to play the modular synthesizer 🎛️🎚️