Secure and Recommended OpenZiti Deployment?

Support General Questions
1

Hi All,

I have set up 3 Ubuntu VMs, each residing in its own VLAN, as described in my current setup here:

I plan to add Microsoft Entra ID for authentication, following the guide here:

My main concerns are:

Is this setup secure and recommended to expose port 443 from my WAN directly to VM1 and VM2?

I’ve created a cron job to keep all components up to date. Is this sufficient for maintaining OpenZiti security and stability?

Currently, I intend to deploy the applications I need through ZTNA on VM3 (which acts as a private router). In the future, I plan to set up ZTHA. Are there better best practices or deployment patterns you recommend?

I run many open-source tools internally and test them thoroughly, but this is the first open-source tool I am exposing to the internet. Since it will have access to nearly all my internal resources, I want to make sure I’m doing this as securely as possible.

Additional context:

I also plan to install my EDR and RMM agents on the Ubuntu VMs for added security.

Any tips on improving security, hardening the setup, or avoiding common pitfalls would be greatly appreciated.

Thank you in advance for your guidance!

2

Hi @Sjoerd_van_Eindhoven, welcome to the community and to OpenZiti!

An OpenZiti overlay requires one port for at least one controller and one port for at least one router to be availalbe across whatever network you want to secure. This is generally, the entire internet (most people are looking for secure, ubiquitous connectivity). Your controller and your router must be availalbe to all clients connecting to the data plane.

I'm not exactly sure how your topology works, but if your controller is on VM1 and router is on VM2 and you plan to have these available from anywhere, then yes they need to be exposed to the internet and it's secure and recommended.

I would not update using cron. I would update after reading the release notes and making sure there are no issues that you'll need to address. Sometimes we find and fix bugs and if you just update them automatically it's possible you'll miss some interim step that's important. Also you need to have a backup/disaster recovery plan.

Everybody has a different zero trust journey, this seems entirely reasonable to me. If you have your own apps, embedding OpenZiti into those apps via SDKs is the next logical step. If not, ZTHA is as good as you can get without going app-embedded (ZTAA).

Entirely understandable. That's why OpenZiti fits so nicely. OpenZiti itself won't have access to any resoruces, you will need to explicitly grant access to each identity to each service and OpenZiti makes it easy to group services into 'buckets' to make that authorizing easier through attributes. OpenZiti is the only thing you would expose directly on the internet.

The only other thing I suggest you should look into is "splitting the management api". This will ensure the API that is responsible for network mutations (create/update/deletes) is only available from private address space. Often, I'll bind that api to 127.0.0.1 so that it can only be accessed from the controller itself (for example). There are numerous videos on YouTube that cover this and numerous forum posts here that cover this.

Enjoy!

3

Hi @TheLumberjack

Thanks for your reply. You’re absolutely right—VM1 and VM2 serve as the controller and the public router.

Given that these services are exposed to the public internet, I want to ensure they are kept up to date as quickly as possible. That’s why I’ve planned to configure a cron job:
30 2 * * * apt update && apt upgrade -y

Of course, I regularly back up the VMs, so if something breaks due to an update, I can easily roll back to a backup from the previous day.

That said, is there a better approach you’d recommend for keeping both the system and OpenZiti components up to date? Also, is there a mailing list or notification system you’d recommend subscribing to for updates on new OpenZiti releases or security advisories?

Regarding the management API: I believe I’ve configured it correctly, as shown in my config.yml. My understanding is that the management API is now only accessible on port 8443, which is also used by the ZAC. Could you please confirm whether this setup is correct or if there’s anything I might have overlooked?

Thanks again for your help!

4 
  - name: dark-management
    bindPoints:
      - interface: 0.0.0.0:8443

IMO, this is wrong. you're binding to any interface. You would want to bind to a private IP. You will likely then access your ZAC using OpenZiti as well (unless you can log onto that machine's UI).

Also move the fabric api to the dark api too.

5

Hi @TheLumberjack

You're right I’ve set it up that way, using Ubuntu’s UFW (Uncomplicated Firewall) to allow access to port 8443 only from a specific IP address. Additionally, I configured my FortiGate firewall to permit traffic to port 8443 on the controller solely from that same source IP.

This way, if my client ever loses access to the management API, I can still reach it from my management server and continue using ZAC.

Thanks for the tip about moving the Fabric API as well. Based on that, would the configuration look something like this?

I broke my test setup yesterday, but I’ll rebuild it tomorrow and give it another try.