Private interface binding vs security-group gating for FoundationDB cluster reachability

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?