cvm-deployment: example .env files bind external ports to 0.0.0.0 — recommend an explicit public IP

[barakeinav1]

Background

The example env files for deploy-launcher.sh (deployment/cvm-deployment/default.env, configs/sgx.env, configs/kms.env) set all EXTERNAL_MPC_* ports to 0.0.0.0:<port>. Operators copy these as-is, so qemu ends up listening on every host interface (internal/secondary networks included), not just the intended public one. Binding to 0.0.0.0 contributed to an incident on one of our testnet nodes.

User Story

As a node operator, I want the example configs and guide to bind external ports to an explicit host IP, so MPC services are not unintentionally exposed on interfaces I didn't plan for.

Acceptance Criteria

• Example .env files use an explicit placeholder (e.g. EXTERNAL_MPC_MAIN_PORT=<HOST_PUBLIC_IP>:80) or a comment recommending it over 0.0.0.0
• deploy-launcher-guide.md (and/or the external TDX guide) briefly explains choosing the bind IP

Resources

• deployment/cvm-deployment/default.env lines 30–34; same pattern in configs/sgx.env / configs/kms.env

[barakeinav1]

Follow-ups from a Slack discussion on this:

Side effect of binding to an explicit IP: an external operator cannot launch a second CVM on the same machine without a second public IP (same ports, one IP) — and since migration requires the first CVM to keep running, a second IP or a second machine effectively becomes mandatory for migrations.

Additional items for this issue:

• Update/clarify docs/running-multiple-mpc-nodes-on-one-host.md (docs: require every CVM port (incl. migration :8079) bound to a dedicated IP #3458) to spell out this constraint
• Document the alternative: operators are already required to have a backup server — the second (migration-target) CVM can run there instead of a second IP on the same host