Taming Temporary Server Chaos with OpenZiti

Let me start by painting a picture for you—one that I’m sure many of you can relate to. You’ve got a new project on the horizon, a tight deadline, and the need to spin up a handful of temporary servers just to get things off the ground. Maybe it’s a quick proof of concept, or perhaps it’s a staging environment where you’ll be running tests for the next week or two. Sounds simple enough, right? But if you’re anything like me, this is where the headaches start.

I can’t tell you how many times I’ve found myself in this exact scenario. I need those servers up and running, accessible from wherever I am, but the last thing I want to do is expose them that easily to the internet for management. We all know the drill—open ports are just invitations for trouble, and managing access to these servers quickly becomes a rabbit hole of security groups, firewall rules, and SSH key management, VPN's (I've done crazy stuff as adding PortKnocking and configuring each server indivudually). Before you know it, you’re spending more time on security configurations than on the actual work you’re supposed to be doing. 

It’s frustrating, and it feels like every new server is just another task added to an already overflowing to-do list.

Now, if you haven’t yet had the pleasure of working with OpenZiti, let me introduce you to what has quickly become my go-to solution for basically any remote access challenge. OpenZiti allows you to securely connect to your services without exposing a single port to the internet. No more VPNs, no more firewall nightmares—just secure, encrypted connections that work seamlessly in the background.

But here’s the kicker—OpenZiti offers something even better for those of us who regularly deal with temporary servers: Addressable Terminators. This feature has been a game-changer for me, and I’m sure it could do the same for you.

Addressable Terminators take the pain of manually setting up and managing services for each server and distill it into a single, intelligent service that works across all your temporary servers you need (thanks policies). Imagine being able to spin up a server, give it a name, and have it instantly accessible with the services you need (ssh, rdp, you name it), without touching a firewall rule or opening a port. It’s not just a time-saver; it’s a sanity-saver.

So, if you’re tired of wrestling with temporary servers and the security headaches they bring, stick with me. I’m going to show you how Addressable Terminators can make your life a whole lot easier (And maybe in less words that this intro).

First things first, we need to create a host.v1 configuration. This configuration makes use of the "bindUsingEdgeIdentity" which basically tells to the service that the way to "expose" it to the overlay will be using the Name of the Identity. Ohh, and by the way... you can use the CLI or the ZAC Here’s what the configuration looks like:

ziti edge create config TemporaryAccess-Host host.v1 '{
    "address": "127.0.0.1",
    "protocol": "tcp",
    "forwardPort": true,
    "allowedPortRanges": [ {"low":22,"high":22} ],
    "listenOptions": { "bindUsingEdgeIdentity": true }
}'

What we’re doing here is pretty straightforward, we’re telling OpenZiti that when an identity has authorization to bind this service it will host a service on port 22 and "forward" the requests to 127.0.0.1:22. 

Next, we need to set up how the authorized identities will connect to the exposed services. This is where the intercept.v1 configuration comes into play:

ziti edge create config TemporaryAccess-Intercept intercept.v1 '{
    "addresses": ["*.natas"],
    "protocols": ["tcp"],
    "portRanges": [ {"low":22,"high":22} ],
    "dialOptions": { "identity": "$dst_hostname" }
}'

With this configuration, you’re essentially telling OpenZiti, “Hey, whenever someone with the right permissions wants to connect to the service, it can connect with it using the hostname he wants to reach out, as the identitiy (or more simplistically talking, destination) and the port 22”.

Now, let’s tie these configurations together into a service. This service will be what actually facilitates the secure connection between your admin users and the temporary servers:

ziti edge create service TemporarySSH \
    --configs TemporaryAccess-Host,TemporaryAccess-Intercept \
    --role-attributes "#TempService"

This will add our previous configurations into the service.

We’re going to create a bind policy that automatically applies to any identitiy with the TemporaryIdentity attribute. No need to manually tweak settings each time a new server comes online, this policy will handle it all:

ziti edge create service-policy TemporaryAccess-Bind Bind 
    --identity-roles "#TemporaryIdentity" 
    --service-roles "#TempService"

This policy tells OpenZiti, “Whenever a new server with the TemporaryIdentity attribute shows up, bind it to our TemporarySSH service (which as we saw has the attribute TempService).” It’s as simple as that.

Finally, let’s make sure our #TempAdminAccess identities can actually dial into these servers. Here’s the dial policy that will enable that:

ziti edge create service-policy TemporaryAccess-Dial Dial 
    --identity-roles "#TempAdminAccess" 
    --service-roles "#TempService"

This policy is your green light for secure access. Any identity tagged with the attribute #TempAdminAccess will be able to dial (Or connect) into the TemporarySSH service, which, as we’ve defined, gives them secure SSH access to any server marked with the #TempService attribute.

Next time you need to connect to one of your services you may use the TemporaryIdentity

And you can connect immediatly (if your identity has the right attribute):

And that’s it! With these steps in place, you’ve just automated the secure access to your temporary servers. No more fiddling with firewall rules or worrying about security gaps—OpenZiti handles everything in the background, allowing you to focus on what really matters.

Happy Hacking!