Assistance with Implementing OpenZiti over Wazuh Using Docker Compose

Support
1

I am currently attempting to implement OpenZiti over a Wazuh stack (Manager, Indexer, Dashboard, etc.) using Docker Compose. While I have successfully enrolled the services, I am encountering difficulties with the configuration afterward and ensuring proper connectivity between the components.

I would appreciate guidance or references on how to properly configure OpenZiti to secure communication between Wazuh components. My intended approach is as follows:

  1. Deploy Wazuh components via Docker Compose (Manager, Indexer, Dashboard).

  2. Deploy OpenZiti Controller and Routers using Docker Compose.

  3. Enroll each Wazuh service as an OpenZiti edge service to enable secure, zero-trust communication.

  4. Configure OpenZiti Edge Tunnels for each Wazuh component to ensure connectivity without exposing services directly to the network.

  5. Test and validate connectivity between the Wazuh services through OpenZiti to confirm proper network routing.

If anyone has a step-by-step guide, example configuration, or best practices for this integration, it would be extremely helpful.

2

Hello @anshjoshi, Welcome to the community and to OpenZiti. I haven’t come across a guide specifically for Wazuh with OpenZiti, but I did put one together for NetFoundry. The process is very similar—just some terminology and abstractions differ. It should still be a solid reference point if you’re looking to implement it with Wazuh. https://support.netfoundry.io/hc/en-us/articles/14588893503373-NetFoundry-s-CloudZiti-Zero-Trust-overlay-for-secure-log-collection-and-management-of-SIEM-SOAR-platforms

3

Thanks @sheik.ahamed for this, If i find any difficulties, I will let you know.

4

Hello @sheik.ahamed,

Thank you for sharing the NetFoundry guide — I went through it and tried adapting the steps to my OpenZiti setup. Unfortunately, I wasn’t able to get it working as expected.

My situation is a little different:

  • I’m running the free version of Wazuh on my own home server inside a private network.

  • I already have a public domain (remote.integratedinfosec.com) that can reach the server, but this currently bypasses Ziti completely.

  • What I want is for Wazuh to be accessible only through Ziti (for example via remote.integratedinfosec.com), and not directly over the public domain.

I tried following the same flow (host configs, intercepts, services, policies, and running the Ziti Edge Tunnel), but when I attempt access from outside the LAN, the Ziti service resolution doesn’t work — the hostname isn’t reachable unless I fall back to the public DNS/domain, which defeats the purpose of Ziti.

Could you help clarify the adjustments needed so that:

  1. Wazuh is exposed only to Ziti identities, not directly over the public IP/domain.

  2. The Ziti tunnel resolves the internal hostname (e.g., remote.integratedinfosec.com) correctly on the client side.

Thanks again for pointing me to the NetFoundry reference — I think I’m close, but must be missing some step to force Ziti-only access.

Best regards,
Ansh Joshi

5

What does your service configuration look like? The remote.integratedaccess.com should be an intercept address for the service, and the endpoint have dial permissions in order to allow it to resolve the address as a service. If you ping the service name locally, you should see a 100.64.X.X address, which will indicate the service is resolving to the ziti process.

The ziti CLI has a policy advisor that can verify the dial and bind policies. See the policy advisor section of this page.

Nothing in OpenZiti will block the access natively. You should use the local tools, such as ufw, or whatever is appropriate to the OS or environment, to block access from non Ziti enabled nodes.