Securing the admin surface (the loopback trick)

Kong's Admin API is powerful — it can reconfigure the whole gateway — and the open-source edition has no built-in authentication on it (that's a paid feature). So you must not expose it casually. Two honest options:

Leave it internal. The ingress controller talks to it inside the pod; nothing outside the cluster can reach it. Simplest and safest.
Expose it, but put a password in front using Kong itself — the "loopback" trick.

I wanted the second so the admin API and the Kong Manager GUI are reachable (for demonstration), so I routed them back through Kong's own proxy and attached Kong's basic-auth plugin:

one host:  kong-admin.example.com
   /       ->  Kong Manager GUI   (basic-auth)
   /api    ->  Kong Admin API     (basic-auth, path stripped)
   credentials: admin / <REDACTED>

Putting both the GUI and the API under one hostname, split by path is the detail that makes it actually usable. An earlier attempt split them across two hostnames; the GUI is a browser app that calls the API, and across two origins that means CORS headaches and double login prompts. Same origin → one login, no CORS, the browser just carries the credential. Same destination, far less friction.

Lesson learned: when a product's free tier has "no auth on the admin interface," that's not a dead end — you put your own gate in front of it. And when a web UI talks to an API, keep them on the same origin unless you enjoy debugging CORS. The two-hostname version technically worked and was miserable; the same-origin version is boring and works.