Clint (who among other things, does all sorts of OpenZiti development and co-hosts Ziti TV with me) recently posted a video, OpenZiti 2.0: A Management API With No Open Port.
It’s a quick but deep dive prompted by a great question over on our Discourse forums: “What’s the service configuration for the hosts part when using identity?”
Short answer: there isn’t one. No host.v1, no tunneler hosting it.
The core idea: in 2.0+, the controller is the hosting app. Give it an identity and it binds the service itself. There’s no separate tunneler, no host config. That’s the whole trick behind darkening an API you’d normally have no choice but to expose.
What the demo does: starting from a fresh 2.0.2 quickstart, Clint splits the controller’s APIs across two web listeners. The edge client and OIDC APIs stay on the public listener (0.0.0.0:1280). The management API gets no internet-facing port at all! It’s bound to the controller’s own Ziti identity and reachable only over the overlay by identities authorized to dial it. Then he proves it three ways: over loopback, with the ziti CLI over the overlay, and with a plain curl through ziti-edge-tunnel.
Before you try this in your own lab:
- The intercept hostname has to be in the listener’s server cert. Recreate the server cert to include the intercept name (
management.zin the demo), or thezitiCLI won’t connect over the overlay. - The edge-oidc snag. The moment you split listeners, edge-oidc’s auto-binding will bite you. It’s tracked in openziti/ziti#4185. If you’d like confirmation you’re not losing your mind, there’s a matching Discourse thread from folks whose
ziti edge loginbroke on 2.0.0 right after a split.
Resources:
- Watch it on YouTube
- Command gist with every command from the demo, copy/paste ready
- v2.0.0 release notes, with more on binding controller APIs with an identity