CouchDB and sidecar proxy: internal‑only bind address considerations

Integration goal

Run CouchDB inside a Kubernetes pod alongside a sidecar proxy that terminates TLS and forwards traffic to CouchDB's HTTP endpoint. The goal is to make CouchDB reachable only from the sidecar (and other trusted pods) while preventing accidental exposure to the cluster network or the internet.

Constraints and uncertainty

CouchDB's bind_address defaults to 0.0.0.0:5984, which listens on all interfaces. Changing this setting requires a restart of the CouchDB process, which may cause downtime if done after deployment. Additionally, the admin party mode is active when no admin users are defined, allowing any client that can reach the port to perform administrative actions. It is unclear whether relying solely on network policies or service mesh to restrict access is sufficient, or whether the bind address should be tightened to the loopback interface and authentication enforced.

• What is the safest bind_address value to use when CouchDB shares a pod with a sidecar proxy, considering the need to avoid restart‑induced downtime?
• Should require_valid_user = true be enabled in addition to network‑level isolation, or does the latter alone mitigate the admin‑party risk?
• How can an operator verify that CouchDB is not listening on external interfaces without restarting the service or exposing a test port?