An ingress-controller isn't really a special workload compared to other workloads/services deployed to the cluster. Mapping external traffic into the cluster happens because the Service of the ingress controller is exposed to the outside (in most cases) using the type: LoadBalancer which triggers the cloud infrastructure to provide a public IP and a cloud load balancer that maps to the cluster VMs (on the service exposed ports).

Nobody prevents you from not setting that service type to LoadBalancer effectively making your ingress-controller internal. If you want to use custom domain names, that will require some DNS CNAME records pointing to your cluster-local service name of the ingress-controller, but that is definitely possible.

Please make sure how your ingress-controller of choice is deployed exactly. Some use DaemonSets and HostPorts for performance reasons, which means you need to take extra care for your firewall setup.

Nevertheless, you should consider if you really want to use an ingress-controller here as with running your real services internally, you already have stable DNS names you can use. Using an ingress-controller introduces additional hops of your packets as the request first goes to an ingress controller instance (which could be running on a different node) and then is forwarded to the real target workload.

If you have a fixed set of workloads, you could also go with an nginx deployment to handle that proxying/rewriting of urls and paths. Check the nginx docs for some sample config. From a networking perspective, that's not really different to the ingress-controller setup and also introduces the additional hop.