Repository navigation
Redis: TLS support for client-facing connections #2157
Description
Summary
Add TLS encryption for client-facing Redis connections using an nginx stream module sidecar.
Context
The Spotahome Redis Operator does not support TLS natively — its internal Redis client, health probes, and sentinel monitoring all use plaintext TCP. Adding full TLS encryption for all traffic (replication, sentinel, operator) is not feasible without significant operator modifications (see below).
However, client-facing TLS can be implemented independently by adding an nginx sidecar that terminates TLS and proxies to the local Redis process over plaintext.
Proposed Solution
Add an nginx stream sidecar container to the Redis pods:
- nginx listens on a TLS port (e.g.,
6380) with a certificate (cert-manager issued or user-provided) - nginx proxies decrypted traffic to
localhost:6379 - The existing plaintext port remains available for intra-cluster communication (operator, sentinel, replication)
- When
external: true, the LoadBalancer Service points to the TLS port
Certificate Management
Either integrate with cert-manager for automatic certificate provisioning, or accept a user-provided TLS secret reference in values.yaml.
Why full inter-replica encryption is not feasible with the current operator
The Spotahome Redis Operator manages replication by issuing SLAVEOF <pod-ip> <port> commands using raw pod IPs (see operator/redisfailover/service/heal.go). The operator's own reconciliation loop, health checks, and sentinel configuration all connect directly to pod IPs over plaintext TCP via its built-in Go Redis client (service/redis/client.go). Encrypting replication and sentinel traffic would require either:
- Patching the operator to use TLS-enabled Redis connections and TLS-aware sentinel configuration
- Deploying a service mesh (Istio/Linkerd) for transparent mTLS at the network layer
Both are out of scope for this issue.
Acceptance Criteria
- nginx stream sidecar added to Redis pods when TLS is enabled
- New
tls.enabledandtls.secretName(or cert-manager integration) fields invalues.yaml - External LoadBalancer Service routes to the TLS port when both
externalandtls.enabledare true - Intra-cluster traffic (replication, sentinel, operator probes) continues to work over plaintext
- Documentation on how to configure TLS
Activity
Arsolitt commentedon May 15, 2026
Changing approach: closing this in favour of forking the Spotahome operator instead of the nginx sidecar workaround.
Rationale: a sidecar only encrypts the client-facing port — operator probes, sentinel monitoring, and replication still run in plaintext, which is below the bar for the rest of cozystack's DBaaS offering. The upstream operator is unmaintained and won't upstream TLS, so the only path to full TLS coverage is a fork.
Follow-up: #2662