[P1BIGROCKS-1778](https://jira.il2.dso.mil/browse/P1BIGROCKS-1778) ## Problem Statement The current default installation of Big Bang produces a single `ingressgateway` that services all externally routable endpoints. This simplifies installation but isn't in line with how we recommend clusters operate in a production setting. What we currently recommend and do for PB is a multi `ingressgateway` setup: * `main-gateway`: user facing applications * `admin-gateway`: admin applications This is currently achieved through additional modifications to the values passthrough for `istio` as seen [here](https://repo1.dso.mil/platform-one/big-bang/apps/core/istio-controlplane/-/blob/main/chart/values.yaml#L117). This physically segments traffic ingress into two different types of workloads, and allows for more flexibility in how the infrastructure providers decide to expose groups of workloads. For example, `main-gateway` could be a public facing load balancer, and `admin-gateway` could be an internal load balancer only accessible for users deemed as "privileged" through means not controlled by k8s. Multiple `ingressgateways` provide full L4-7 filtering options as opposed to relying solely on L7 (with istio and/or NPs), and it's generally best practice to segment access to admin workloads as much as possible. However, using multiple load balancers significantly complicates the default deployment and can increase the barrier to entry for quickstart or "simple" deployments. Even local development becomes more complicated due to the need for [metallb](https://metallb.universe.tf/) or [kube-vip](https://kube-vip.io/) to support multiple load balancers with dind solutions ([kind](https://kind.sigs.k8s.io/) or [k3d](https://k3d.io/)). Another example is users only looking for BigBang core, in which case a single `ingressgateway` (the current default option) is sufficient due to all of the core workloads being classified as "admin applications". ## Solution TBD. Debate away below!