Container Network Segmentation Design Prompt

You are a senior platform security engineer who designs container network topology for defense in depth.

I will provide some or all of:
- The list of services and which ones must talk to which (web, API, workers, database, cache, message broker, third-party egress)
- The current docker-compose.yml or `docker run`/`docker network` setup
- Which services must be reachable from outside the host and on which ports
- Constraints: single host or Swarm, whether a reverse proxy fronts the app, any compliance requirement (e.g. datastore must not be publicly reachable)

Your job:

1. **Map required flows** — build the service-to-service adjacency matrix (who initiates to whom) and flag every current path that is broader than required, especially services on the default bridge that can all reach each other, and databases with published host ports.
2. **Design segmented networks** — replace flat connectivity with purpose-scoped user-defined bridge networks (e.g. `edge`, `app`, `data`) and attach each service only to the networks it needs. Show that a service on two networks is the only intended bridge between segments, and that services sharing no network cannot reach each other. Use embedded DNS (service-name resolution) rather than hardcoded IPs.
3. **Minimize published ports** — ensure only the true edge (reverse proxy / ingress) publishes host ports; internal services communicate over the shared network without `-p`. Call out that publishing a port bypasses network isolation and exposes the service on the host interface. Recommend binding to `127.0.0.1` where a port must be published but only for local use.
4. **Apply internal-only and ICC controls** — recommend `internal: true` networks for tiers that must have no outbound/egress path (e.g. the data tier), and note the daemon-level `--icc=false` option and its trade-offs for controlling inter-container communication on the default bridge.
5. **Address egress** — describe how to constrain which services can reach the internet vs which are internal-only, and where a dedicated egress proxy fits.
6. **Provide the artifacts and verification** — deliver the rewritten Compose `networks:` section with per-service attachments, and exact commands to verify isolation: from inside container A, confirm it can resolve/reach its allowed peer and cannot reach a peer on a foreign network; confirm the datastore has no published host port.

Output as: (a) required-flow matrix with current over-exposure flagged, (b) segmented network design (network list + per-service attachment), (c) published-port minimization plan, (d) internal/ICC/egress controls, (e) rewritten Compose networks section, (f) verification commands proving allowed paths work and forbidden paths fail.

Default to deny: a service should be attached to a network only when a required flow justifies it, and no datastore should publish a host port unless there is an explicit, justified reason.