Automating Redis TLS certificate management with 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.
- Sign up for Smallstep if you haven't already.
- In the Devices tab, create a collection and register a device that will run Redis. You'll need a machine to register. A cloud VM running Ubuntu/Debian is a great option—we seamlessly support Azure, AWS, and GCP virtual machines.
- Install and configure the Smallstep Agent on your VM.
- Install Redis on your VM.
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.
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-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.
To connect to your Redis workload, the Certificate Authority's root certificate must be downloaded and trusted in your clients.
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
--install flag is optional. It will install the root CA certificate in your system trust store.
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
Your Redis server connections are now encrypted with TLS.
How you operationalize Smallstep is going to depend on your deployment method and context.
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.
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.crtdirectly to the
ca-ceritficatesbundle on linux VMs so running applications trust the API servers they call
root_ca.crtdirectly into base Docker images for gRPC so gRPC clients can always reference the trusted CA
root_ca.crtin a Kubernetes
Secretand inject it into an environment variable for access from application code
- Use Jamf to install
root_ca.crtin the trust stores of every employee Macbook so their web browsers trust internal websites
- Use Puppet to run
step ca bootstrapwith
--installon target machines that you want to implicity trust the CA
ca.crtin a Kubernetes
ConfigMapand mount it to pods for reference on the filesystem
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 🎛️🎚️