Hacktoberfest 2026:维护者为十月标记出来的 issue,仍然开放、适合新手。 浏览 Hacktoberfest issue

[Feature] Support TLS for inter-node and client-to-cluster connections

未关闭
#69 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 2 天内回复

还没有人认领这个 Issue。

评估

难度
5/5
预计耗时
一周以上
新手友好度
35/100
Issue 类型
功能
描述清晰度
基本清楚
活跃度
活跃
技术栈
go, kubernetes, redis

调研方向

从内部提案文档 09-tls-support.md 开始,然后检查其中指出的 RedkeyCluster CRD、operator、Robin、Redis 配置、probes、Makefile 和示例 manifests。追踪配置、Secret 挂载、客户端连接和集群连接目前是如何组装的。完成的标准是:opt-in TLS 保持现有行为,覆盖列出的流量路径,支持轮换和 mTLS 要求,并通过证书工作流完成文档化。

由索引模型根据 Issue 内容生成。

描述

enhancement security
Feature description

Summary

Redkey currently does not support TLS encryption for Redis traffic. All
communication happens in plaintext, both between cluster nodes (cluster bus
/ gossip and replication) and from clients to the cluster. We would like to
propose adding optional TLS support so that all Redis connections can be
encrypted.

Problem / Motivation

Today, a RedkeyCluster exposes and uses unencrypted Redis connections:

  • Client → Redis: application traffic travels in plaintext.
  • Redis → Redis: the cluster bus (node-to-node gossip) and replication
    streams are unencrypted.
  • Robin → Redis: management commands and metrics collection are unencrypted.

This is a blocker for:

  • Compliance: regulatory frameworks such as PCI-DSS and SOC 2 require
    encryption of data in transit.
  • Zero-trust networking: Kubernetes NetworkPolicy only protects at L4;
    TLS adds encryption at the transport layer.
  • Multi-tenant clusters: without TLS, Redis traffic can be observed by other
    workloads sharing the network.

Proposed Solution

Add an opt-in, disabled-by-default TLS configuration to the RedkeyCluster
CRD. When enabled, all Redis connections (client, cluster bus, replication, and
Robin management traffic) are encrypted.

High-level scope:

  1. CRD: new spec.tls block referencing a Kubernetes TLS Secret
    (tls.crt, tls.key, ca.crt), with an option to enable mutual TLS (mTLS)
    between nodes.
  2. Operator: when TLS is enabled, inject the relevant redis.conf settings
    (tls-port, tls-cert-file, tls-key-file, tls-ca-cert-file,
    tls-replication yes, tls-cluster yes), mount the certificate Secret into
    the Redis pods, and update liveness/readiness probes to use redis-cli --tls.
  3. Robin: support TLS when connecting to Redis (go-redis tls.Config) and
    when invoking redis-cli subcommands (--tls --cert --key --cacert).
  4. Certificate management: the operator consumes an existing Secret and does
    not generate certificates. Certificate lifecycle is managed externally
    (cert-manager recommended, with support for manual OpenSSL generation or an
    external PKI such as HashiCorp Vault).
Example CRD usage
apiVersion: redkey.inditex.dev/v1beta1
kind: RedkeyCluster
metadata:
  name: redkeycluster-sample
spec:
  primaries: 3
  image: redis:7.4.2
  tls:
    enabled: true
    secretName: redkey-tls
    mutualTLS: true

Requirements

  • TLS is opt-in and disabled by default; existing clusters keep
    working unchanged.
  • Encrypt client → cluster connections.
  • Encrypt node → node connections (cluster bus and replication).
  • Encrypt Robin → Redis management and metrics traffic.
  • Optional mutual TLS (mTLS) between cluster nodes.
  • Certificates are provided via an external Kubernetes Secret; the
    operator does not generate them.
  • Documented certificate workflow (cert-manager, OpenSSL, external PKI).
  • Support for certificate rotation without data loss.

Out of Scope

  • Automatic certificate generation by the operator.
  • Certificate authority (CA) lifecycle management.

Additional Context

A detailed technical design (CRD changes, operator and Robin changes, certificate
generation options, Makefile integration, sample manifests, rotation, and
compatibility) is available in the internal proposal document
09-tls-support.md.

Use case or motivation

No response

Would you like to work on this?

Yes, I'd like to open a PR

主要语言
Go
星标
20
派生
2
平均合并
1 天 18 小时
30 天内合并 PR
11

环境准备

在 Codespaces 中打开

在浏览器里用你自己的 GitHub 账号启动这个项目的开发容器。

从这里开始

  1. 先读完整个 Issue,再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库,在一个分支上完成修改。
  4. 提交 Pull Request,并在描述里引用这个 Issue 编号。

InditexTech/redkey-operator 的其他 Issue

查看 InditexTech/redkey-operator 的全部 Issue

相似的 Issue

更多 Go Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。