Two Redis Ports, One TLS Boundary

A Redis Cluster node can expose a client port and a cluster bus port. The first carries application commands; the second carries node-to-node cluster traffic. Enabling TLS only for application clients leaves a second network path that deserves its own review.

The cluster bus is a separate path

Redis documentation describes each cluster node as needing a client TCP port, commonly 6379, and a cluster bus port. The bus port is used for cluster communication. It is not an ordinary application endpoint, even when it is reachable from the same network segment.

The TLS documentation states that tls-cluster yes enables TLS for the cluster bus and cross-node connections when Redis Cluster is used. Replication links are another communication path. Teams should check the relevant replication setting as well if replicas are part of the deployment.

The practical consequence is that a network scan can find two listeners and report different protocol behavior. A client certificate policy on the application endpoint does not automatically describe the cluster bus. Inventory both ports, the listening addresses, and the certificate or key material used by each node.

Shared names are not shared trust

Cluster nodes need a consistent view of node identity and reachability. Certificate names, client authentication requirements, and address announcements can affect both security and cluster formation. Changing a certificate can break a node's connection to peers even when ordinary clients still connect.

Use a test cluster with the same node count and network layout as production, if possible. Verify peer discovery, failover, and a rolling restart. Check that a node rejects a client certificate it should not trust. Then check cluster traffic from an address that should not be a member. Test both client and peer paths before treating the rollout as complete.

Avoid placing files with cluster credentials or private keys in a container layer that is copied to every role. Mount them with the right ownership and rotate them through a process that accounts for all nodes. Keep the private key out of logs and command arguments.

Announcement addresses need review

Redis Cluster is sensitive to how nodes announce addresses and ports. A setting that works inside one Docker network may produce an address that remote clients or peers cannot reach. This can lead an operator to broaden firewall rules until the cluster works, which is a poor way to discover the intended network boundary.

Record the announced address, client address, and bus address separately. Compare them with the DNS names and network policies used by applications. If a proxy or NAT layer changes the path, document the translation and test from both sides.

A rollout checklist

1. Confirm that the client and bus ports are both in the asset inventory.
2. Review tls-cluster and replication TLS settings on every node.
3. Verify certificate names, trust roots, and client-authentication policy.
4. Test peer join, failover, and restart on a disposable cluster.
5. Test denied peer and client paths from outside the intended networks.
6. Keep a rollback node configuration and a certificate rollback path.

After rollout, monitor for nodes that repeatedly join and leave or report certificate errors. A cluster that appears healthy from one node can still have one peer using a weaker path. The useful evidence is a complete map of listeners and a tested rejection for each path, with no unencrypted bus ports left behind.

References

• Redis TLS documentation
• Redis cluster specification