Support network.ingress.hostLoopback: "allow" without requiring callers to supply a port-forwarding list.
| Example |
Expected behaviour |
| Host-loopback access allowed |
The workload can reach services on host loopback, and the host can reach services listening inside the workload. |
Host-loopback allowed, ingress.default: "deny" |
Host-loopback connections work, but other private-network inbound connections remain blocked. |
| Host-loopback access denied |
Block both directions between host loopback and the workload. |
| Host-loopback denied with a configured proxy |
Preserve only the existing outbound exception to the exact TCP proxy endpoint. |
Do not expose workload listeners through the host's LAN/public interfaces. Keep loopback communication between processes inside the same sandbox separate from host-loopback access.
Verify both directions with real workloads. Existing explicit TCP/UDP forwards should continue to work.
MXC schema requirement: network.ingress.hostLoopback, with semantics defined in the networking contract.
Support
network.ingress.hostLoopback: "allow"without requiring callers to supply a port-forwarding list.ingress.default: "deny"Do not expose workload listeners through the host's LAN/public interfaces. Keep loopback communication between processes inside the same sandbox separate from host-loopback access.
Verify both directions with real workloads. Existing explicit TCP/UDP forwards should continue to work.
MXC schema requirement:
network.ingress.hostLoopback, with semantics defined in the networking contract.