I found the option to use the SNI flag on the command redis-cli, how can I configure sni as part of my replication configuration?

after reading your doc, I found out that I can use cluster-announce-hostname, but when I try to configure that I get an error. (error) ERR Unsupported CONFIG parameter: cluster-announce-hostname

Comment From: madolson

Hey. We provide an example file here https://github.com/redis/redis/blob/unstable/redis.conf. This specific config was was added in Redis 7.0, so make sure you are running at least that version.

Comment From: navesimchi

I read the configuration a lot of times but didn’t find a way to add SNI to the master dns in the configuration file. I want the equivalent configuration parameter to —sni in the redis-cli

Thank you, Nave


From: Madelyn Olson @.> Sent: Thursday, June 29, 2023 11:05:45 PM To: redis/redis @.> Cc: Nave Simchi @.>; Author @.> Subject: Re: [redis/redis] Redis configuration file example (Issue #12365)

Hey. We provide an example file here https://github.com/redis/redis/blob/unstable/redis.conf. This specific config was was added in Redis 7.0, so make sure you are running at least that version.

— Reply to this email directly, view it on GitHubhttps://github.com/redis/redis/issues/12365#issuecomment-1613741862, or unsubscribehttps://github.com/notifications/unsubscribe-auth/A4FDLW5OLQJ4TJGUIOEW34TXNXNZTANCNFSM6AAAAAAZYQLOOI. You are receiving this because you authored the thread.Message ID: @.***>

Comment From: talsh5528

Hey. We provide an example file here https://github.com/redis/redis/blob/unstable/redis.conf. This specific config was was added in Redis 7.0, so make sure you are running at least that version.

I am trying to so something similar and I found out the --sni flag in redis-cli but not as part of the redis. conf. your configuration mentions something like cluster-announce-hostnamebut I get an error when I am using this parameter. what can I do? i am trying to replicate redis master and redis slave using SNI.

Comment From: madolson

@talsh5528 @navesimchi Are you two actually looking for SNI (https://en.wikipedia.org/wiki/Server_Name_Indication) for replication? Which would imply that you the IP/Hostname you are connecting to is not the same as the one being advertised by the master. This seems unlikely to me. It would help to have a more complete understanding of your use case.

cluster-announce-hostname "example.com" is a valid configuration for Redis 7.0+ running with Redis cluster, not standalone.

Comment From: navesimchi

@madolson We are using Redis 7.0. We have a Redis master deployed on Kubernetes, and its ingress rule is configured to point to the Redis master. Additionally, we have another Kubernetes cluster with vnet peering, allowing it to access the ingress on the first Kubernetes cluster. Our objective is to enable the Redis slave in the second cluster to replicate from the master in the first cluster.

The Redis slave has a host record that resembles the following: redis-master.example.com

In the configuration file, we have the following line:

slaveof redis-master.example.com 443

However, an error message is displayed, stating "Certificate verify failed." To troubleshoot this, we accessed the slave pod and attempted to run the command: redis-cli --verbose --tls -p 443 -h redis-master.example.com --cert --cacert --key Unfortunately, the command returned the same error in the replication log.

However, when we ran the command with the additional parameter: redis-cli --verbose --tls -p 443 -h redis-master.example.com --cert --cacert --key --sni redis-master.example.com it worked successfully.

Based on our observations, we believe that without the --sni parameter, the command reaches the ingress without the host header because it operates at the transport layer (layer 4) of TCP.

Here is the ingress rule defined: apiVersion: networking.k8s.io/v1 kind: Ingress metadata: annotations: kubernetes.io/ingress.class: nginx nginx.ingress.kubernetes.io/ssl-passthrough: "true" name: <ingress rule name> namespace: <namespace> spec: rules: - host: redis-master.example.com http: paths: - backend: service: name: <redis master service name> port: number: <redis master tls port> path: / pathType: ImplementationSpecific Source: Redis Documentation - Kubernetes Ingress

Please note that the information provided here is based on the assumption that the absence of the --sni parameter causes the command to reach the ingress without the appropriate host header due to the transport layer (layer 4) of TCP being utilized.

Comment From: madolson

Are you using Redis Enterprise?

Comment From: navesimchi

No, is it relevant?

Comment From: madolson

No, is it relevant?

Could have been, it looks like you sent the redis enterprise documentation, so just wanted to check.

This might be resolved with https://github.com/redis/redis/pull/11458, which was merged and only available for Redis 7.2. This changes the replication to always send the SNI if available. If you are using the OSS version, can you try using the 7.2 RC to see if it resolves your issue?

Comment From: navesimchi

I understand that the mentioned ingress rule is applicable to the Redis Enterprise documentation, but it should also be applicable to the open-source version. It appears that the solution you provided aligns perfectly with our requirements. I will test it out and keep you informed about the results.

Comment From: navesimchi

@madolson It worked. Thank you very much.

Comment From: talsh5528

No, is it relevant?

Could have been, it looks like you sent the Redis enterprise documentation, so just wanted to check.

This might be resolved with #11458, which was merged and only available for Redis 7.2. This changes the replication to always send the SNI if available. If you are using the OSS version, can you try using the 7.2 RC to see if it resolves your issue?

this works perfectly! thank you very much! we used this image: https://hub.docker.com/layers/library/redis/7.2-rc/images/sha256-31bbc5770405b65bf3cfa7de27023dfb85aa8ad2586d5a33002d57ff2fb88058?context=repo&tab=vulnerabilities

Comment From: madolson

Sounds good. A GA version of 7.2 should be out shortly, otherwise unless you have any other questions I'm going to close this.