Management Plane Goes Zero-Trust

TL;DR: Starting with OpenZiti 1.8, controller APIs can bind as OpenZiti services. The same app-embedded zero-trust that secures your applications now secures the management plane itself.

Application-Embedded Zero-Trust Management

OpenZiti has been bringing zero trust to applications since 2019. Embed an OpenZiti SDK into your app, and it immediately gains significant security benefits—no need to open ports, no need to expose services to IP-based networks, no attack surface on the underlay. Your app becomes dark to the network, accessible only through authenticated identities.

You've always had options when securing the controller's management APIs. Split the APIs off that need to be more secure onto private IPs, use internal networks, and offload to the API through nearby tunnelers. These work great and remain solid approaches. But now there's a new option that takes it further with full application-embedded zero-trust for the controller itself.

What Changed in 1.8

Starting in 1.8, securing those critical APIs changes. Now, XWeb supports overlay-based bindPoints directly! The APIs that shouldn't be exposed to the underlay can be removed from the underlay entirely. Have a look at this bit of controller configuration:

web:
  - name: ziti-management
    bindPoints:
      - identity:
          file: "/path/to/identity.json"
          service: "ziti-controller-api"
    apis:
      - binding: edge-management
      - binding: fabric

Instead of your bindPoint using an interface and a port like you've been doing for years, now you can specify an OpenZiti identity and bind the Controller APIs directly as OpenZiti services! Now, just like you do with your other services, these critical APIs can be accessed through the OpenZiti overlay itself with no need to bind the services to a tunneler and offload back into private IP space. Naturally, we expect most users will make an identity from their own OpenZiti network; however, you're not limited to using the same overlay you're protecting. If you need or want to use a different OpenZiti overlay to protect the controller's APIs, that's fine. You only need to supply the proper configuration, and the controller will bind the services to the overlay you specify.

Why This Changes Everything

If you're reading this blog, you probably understand already why this is so important.

No attack surface. Your controller doesn't need internet-facing interfaces for sensitive APIs. It's not in DNS. It can't be scanned. Can't be found. Even if an attacker can make local network requests on that private network, those requests can never reach those sensitive APIs.

Manage from anywhere. Only authenticated and authorized identities get access. Period. No VPN. No bastion host. No "are you on the right network" nonsense.

True zero-trust. The network that provides identity-based segmentation for applications now uses identity-based segmentation for its own management plane.

The Bigger Picture

This isn't just a feature. It's philosophical consistency. We tell users: "Don't trust networks. Explicitly trust connections using strong identities. Authenticate and authorize before allowing inbound connections. Hide everything. Verify always."

Routers already authenticate and authorize before connecting. You should be able to do the same with your sensitive management plane APIs, and now with 1.8, you can.

The entire management plane can live behind zero-trust segmentation.

The ziti CLI Goes App-Embedded Too

With controller APIs now exposed as OpenZiti services, the ziti CLI is now able to connect through the overlay just like any other zero-trust application. Enable the ziti CLI to use an overlay network by providing the --network-identity parameter during login, then just use the ziti CLI normally:

ziti edge login mgmt.ziti \
  --network-identity /path/to/network-identity.json \
  --username admin \
  --password admin \

Now, the CLI becomes a zero-trust client. It doesn't need network routes to the controller, doesn't need to know the controller's IP address, and doesn't need firewall exceptions. It just needs a valid identity with the right permissions. Manage your network securely from anywhere. The overlay handles the rest.

No special underlay rules required. Just OpenZiti.

Getting Started

If you're running 1.8+ and want to secure your APIs using an identity, follow these steps:

1. Create an identity for your controller to bind API access with

2. Define a service for your controller APIs and authorize the identity created above

3. Split the sensitive APIs off into a separate web section

4. Update the web section with overlay bindPoints by adding an identity accordingly

5. Create and authorize an identity to use to access (dial) the management plane APIs once secured

The network is the security. Now for everything.

Share the Project

If you find this interesting, please consider starring us on GitHub. It really does help to support the project! And if you haven't seen it yet, check out zrok.io. It's totally free sharing platform built on OpenZiti! It uses the OpenZiti Go SDK since it's a ziti-native application. It's also all open source too!

Tell us how you're using OpenZiti on X twitter, reddit, or over at our Discourse. Or you prefer, check out our content on YouTube if that's more your speed. Regardless of how, we'd love to hear from you.