Skip to content

feat(redis): fork Spotahome redis-operator for native TLS support #2662

Closed

Description

@Arsolitt

Summary

Fork spotahome/redis-operator to add native TLS support for all Redis traffic — client-facing, sentinel monitoring, operator probes, and replication — and switch the cozystack Redis chart to consume the fork's image.

Context

This issue supersedes #2157, which proposed an nginx stream sidecar as a TLS-termination workaround. The sidecar approach (closed PR #2540) leaves all internal traffic (operator probes, sentinel, replication) in plaintext, which is below the bar for a managed DBaaS offering that ships native TLS for every other database (postgres, mariadb, mongodb, etc. — see epic #473).

The upstream Spotahome operator is effectively unmaintained (spotahome/redis-operator#268, spotahome/redis-operator#418) and has no path to native TLS upstream. A fork is the only route to bring Redis to parity with the rest of the DBaaS roster.

Why a fork, not a sidecar

The operator's 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 only the client-facing port via a sidecar still leaves:

  • Replication traffic in plaintext
  • Sentinel monitoring in plaintext
  • Operator → Redis health probes in plaintext

To get full TLS coverage we have to teach the operator (and its embedded Redis client + sentinel config generator) about TLS. That means patching the operator, which means maintaining a fork.

Scope

Phase 1 — Fork bootstrap

  • Fork spotahome/redis-operator under the cozystack GitHub organization (proposed: cozystack/redis-operator).
  • Set up CI that builds and publishes the operator image to the cozystack registry alongside other operator forks.
  • Document the fork rebase / upstream-sync policy.

Phase 2 — Native TLS in the operator

  • Teach the operator's internal Redis Go client (service/redis/client.go) to dial over TLS when configured.
  • Generate tls-port, tls-cert-file, tls-key-file, tls-ca-cert-file config lines for both Redis and Sentinel when TLS is on.
  • Generate tls-replication yes so inter-replica traffic is encrypted.
  • Generate TLS-aware Sentinel config and inter-sentinel comms.
  • Make the operator's health/liveness probes TLS-aware.
  • Expose spec.tls.{enabled, secretName, caSecretName} fields (or similar) on the RedisFailover CRD.

Phase 3 — Cozystack chart integration

  • packages/system/redis-operator/ — switch to the forked image; bump CRD if needed.
  • packages/apps/redis/values.yaml — add tls.enabled per the DBaaS-wide convention (epic Add TLS auto configuration on DBaaS #473): unset by default; auto-on when external: true; explicit override always wins.
  • packages/apps/redis/templates/certmanager.yaml — render the standard cert-manager chain (Issuer selfsigned + CA Certificate + CA Issuer + leaf Certificate) aligned with the other DBs.
  • packages/apps/redis/templates/redisfailover.yaml — conditional spec.tls.* fields pointing at the cert-manager-issued secret.
  • packages/system/redis-rd/cozyrds/redis.yaml — extend openAPISchema + secrets.include to expose CA + cert to tenants.

Acceptance criteria

  • Fork repo exists with CI building and publishing the operator image
  • Operator natively accepts TLS configuration on the RedisFailover CRD
  • All operator → Redis / operator → Sentinel / Sentinel → Redis / Redis → Redis traffic is encrypted when TLS is on
  • Cozystack Redis chart consumes the forked operator image
  • tls.enabled follows the DBaaS-wide convention (epic Add TLS auto configuration on DBaaS #473): auto-on with external: true, explicit override wins
  • cert-manager-issued certs are rendered by the chart, not by an external workaround
  • Existing non-TLS clusters keep working after upgrade (TLS not forced)
  • Documentation on configuring TLS for Redis in cozystack docs

References

Activity

  1. added
    kind/featureCategorizes issue or PR as related to a new feature
    area/databaseIssues or PRs related to managed databases (postgres, mariadb, redis, etcd, kafka, clickhouse)
    on May 15, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Labels

area/databaseIssues or PRs related to managed databases (postgres, mariadb, redis, etcd, kafka, clickhouse)kind/featureCategorizes issue or PR as related to a new featuresecuritySecurity-related issues and features

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions