I am using Kong as Api Gateway in AKS. I would like to expose public routes for frontend and different internal routes for the API pods, but when creating the routes they always end up being public.
I did a test to generate a second internal loadbalancer but I can’t find a way to create a custom class for kong (for example: kong-internal) that points to the new loadbalancer, so I can call it when creating the internal route for the APIs with: kubernetes.io/ingress.class: kong-internal
Maybe you can use host based Ingress rules to differentiate between internal and external routes? I think then you only need to add some internal DNS aliases to your loadbalancer and let Kong route those to your internal API’s?
Not one 100% sure but that might even work with a Kubernetes service pointing towards Kong internally. And then use the service DNS name in your Ingress routing rules.
I’ve solved it in an alternative way, but I’m not really convinced. I have deployed a second installation of Kong (in another namespace Kong-internal) where I have passed annotations for it to work locally, including a new class kong-internal. This way I choose when I create a route if I use the Kong class for public or Kong-internal for local. Then I have modified the CoreDNS of kubernetes to add a subdomain that points to the internal IP of Kong-Internal this subdomain is the one that I will use in the routes of Kong-Internal.
This should be resolved by the Kong installation itself and not have to replicate resources to service other types of requests.
Kong exposes all routes on its proxy listen, so even if you have listen configuration for both external and internal addresses, “internal” routes are exposed on both the external and internal addresses. The DNS-based solution mentioned by @erikhh doesn’t truly isolate them since clients can ignore DNS and send a request for an internal hostname to the external IP–Kong will still route that request the same as if it’d come in to the internal IP.
Using a separate instance is the simplest option for segregating traffic, since your internal instance will only listen on an internally-routeable address.
The other option, with a single instance, is to use the IP restriction plugin to limit internal routes to an internal netmask. This option requires more configuration, since you need to add that plugin to each individual internal route.