A cluster demands a credential on its public client address but accepts any connection on another of its addresses — how?

## One cluster, several front doors A broker cluster is not reached at a single address. Most self-run clusters answer on several **separately-configured endpoints**, each with its own authentication rule and its own encryption rule: - the **public client edge** applications connect to; - an **internal or administrative address**, often reachable only from inside a network, used for setup, tooling and colocated clients; - the **node-to-node hop**, over which members replicate records and coordinate with each other. Because the rule is attached to the endpoint, "the cluster requires authentication" is never a property of a cluster. It is a property of one address, and the answer for the cluster is a list. | Endpoint | Who can usually reach it | What it exists for | Usual state | |---|---|---|---| | Public client edge | Applications, sometimes across networks | Normal produce and consume traffic | Authenticated, because it is the one that gets reviewed | | Internal or administrative | Anything routable inside the network | Setup, tooling, colocated clients | Frequently left open | | Node-to-node hop | Cluster members | Replication and coordination | Varies: sometimes its own identity, sometimes trusted outright | ## Why the internal one is the one left open 1. **It is the one that worked first.** A cluster comes up on it before any mechanism is configured; the public edge is hardened afterwards, and the address that bootstrapped everything is never revisited. 2. **Nothing breaks if it stays open.** No application fails, no alert fires, and a change that can only break things and never fix one is a change nobody schedules. 3. **The network is mistaken for a control.** "It is only on the internal network" is a statement about who can route a packet, not about who the connecting party is. It does not distinguish a legitimate service from a compromised one beside it, a laptop with a route, or another team's workload sharing the same network. 4. **Clients can be steered onto it by accident.** On many designs a client's first connection mainly learns which addresses to use for real work. If the cluster hands back the internal address, clients end up on the unauthenticated endpoint without anyone choosing it — and it then looks load-bearing. What varies: a **managed tier** may expose no internal endpoint you can configure at all, in which case the question becomes what the provider did rather than what you set. Some designs give the node-to-node hop a credential of its own; others authenticate members with the same mechanism clients use; a few treat membership itself as the proof. ## What an open endpoint actually hands over A connection there becomes an unnamed identity. Rules written against named principals either do not match it or are skipped entirely, which on many clusters means it can write records into any stream, read retained history back out, and perform administrative operations. Retained history is the part people underestimate: an open endpoint is not only a way to inject records now, it is a way to read everything the cluster has kept. And authenticating an endpoint is not the same as encrypting it. Those are two separate rules on the same address, and turning one on does not turn the other on. ## Closing it without an outage 1. **Enumerate.** For every address the cluster answers on, write down which networks can reach it and which mechanism it demands. The list is usually longer than the operator expects. 2. **Give the node-to-node hop an identity** where the design supports one, so members prove themselves to each other rather than being trusted by position. 3. **Find who is actually using the open endpoint** before removing it. Connection records are the cheap way; the expensive way is discovering it during the change. 4. **Remove it rather than leaving it reachable but unused.** An endpoint that is open and idle is open. 5. **Verify from outside.** Attempt a connection with no credential from each network that can reach the cluster. A configuration file that says the right thing and an endpoint that behaves the right way are different claims. ## What an interviewer is listening for The weak answer is "the internal network is trusted." The strong answer names the mechanism — the rule is per endpoint — then says what that means in practice: that hardening the client edge is the easy half, that the hop between members is a third case with its own answer, and that the order of operations matters because the open endpoint usually has quiet dependents.