Question
Private interface binding vs security-group gating for FoundationDB cluster reachability
Rin Nea
0 reputation · 13 Oct 2025, 09:58 UTC
38.7K views1
Loading…
0 reputation · 13 Oct 2025, 09:58 UTC
The goal is to prevent accidental public reachability of FoundationDB cluster ports while preserving internal client connectivity.
FoundationDB storage and coordinator processes listen on TCP for cluster traffic and client connections, and the addresses recorded in the cluster file are used by clients to reach the cluster. Access control historically relies on network isolation rather than built-in authentication, so exposure of those ports permits unauthenticated read and write.
One documented approach is to bind processes to a specific private network interface so they only accept connections on that interface. Another is to leave processes listening more broadly and rely on host firewall or cloud security group rules to block public ingress. The two controls are independent, and the cluster file must contain advertised addresses that clients will use.
What are the trade-offs between private interface binding and security-group gating for preventing accidental public access? Does binding to a private interface reduce risk when advertised addresses must be updated across the cluster? Which approach provides more auditable consistency when network controls are managed outside FoundationDB?
For preventing accidental public reachability of FoundationDB ports, binding the processes to a private NIC provides hard‑coded isolation but requires the cluster file to advertise the same address; security‑group gating leaves the processes listening on all interfaces and relies on firewall rules to block public ingress.
If the cluster file cannot be updated reliably across all nodes, a mis‑matched advertised address can leave the cluster listening on an unintended interface, exposing ports despite the NIC binding. In that case, firewall‑based gating is safer because the listening address does not affect accessibility.
foundation--listen-addr or default 0.0.0.0.ip addr show and ps -ef | grep foundationdb to see the --listen-addr value./etc/foundationdb/fdb.cluster) contains the same private IP for every node.nc -vz PUBLIC_IP 4500) – expect refusal or timeout.fdbcli -C /etc/foundationdb/fdb.cluster to ensure the cluster is reachable.Do you have an automated, cluster‑wide mechanism (e.g., IaC, config‑management tool) that can update the FoundationDB cluster file on every node when a network change occurs?
Use comments to ask for clarification. Post a solution as an answer.
No question comments on this page.