Reasonable network?

Can I use docker on a single VM to run my entire ziti infra including both private and public edge routers? Do I still need 2 routers in this case? I'm thinking yes to keep those Internal and external security boundaries seperate by container at least. Is there anything I should be aware of with docker networking for this to ensure I'm not unnecessarily exposing anything? I'm thinking I'll just assign each container a dedicated NIC. The simple docker compose on GitHub looks like a good starting point..

Thanks in advance for any insight. Cheers.

Hi @blup66, welcome to the community and to OpenZiti (and zrok/BrowZer)!

Certainly you can. You will "of course" have to expose the controller/public edge router through docker, but definitely. The CPU use on a small network is miniscule, really.

I'm not sure which compose you found, the quickstart or the 'deployment,' but both would likely do the purpose. The deployment ones are trying to target a more production-style (longer running) environment: Deploying with Docker | OpenZiti.

As for a "private" router in docker, that gets trickier because your docker container will only be exposed as much as you allow it to be. By default, that won't be much, so you may choose to use host networking in that case. If ALL your private stuff is within docker though, you could just assign it a network and it'll be fine.

Thanks so much! For the quick reply as well. That makes sense.

I've been trying to read a lot of the posts here and it's awesome and refreshing to see how helpful you have been. OpenZiti is a very interesting and intriguing project. I've enjoyed reading about the project such far in this platform and in the docs, and I'm looking forward to setting up my first attempt at a POC for a potential (very) small business type use case.

Coming from the perspective of looking to replace a couple of aging Any Connect and similar SSLVPN solutions, I'll have many resources that can't be "zitifed" to start. I'm essentially looking to plop a VM with all of the ziti containers in an existing fairly large private network. I have the compute and networking infrastructure to keep everything on prem right now and also want the simplicity of a single VM, including the router that will provide connectivity to my private resources in many rfc1918 blocks, not on the same compute infrastructure but routable from the private router NIC. I'm thinking I can use a seperate NIC for each container, connected to networks that I'll have firewall boundaries between. Does this make sense and sound like a suitable use case?

I was looking at this one as a starting point

1 Like

That sounds like a fun, practical, and perfect use case for OpenZiti!

Eventually you might end up with more and more OpenZiti deployed even in the 'private'/'trusted' network space, but to start, i think this makes a lot of sense yes.

That compose file is a good start to get your feet wet. There are some things the deployment-style docker file might try to do for you that will end up saving trouble. I'd say we're probably going to migrate towards those containers/patters even for the quickstart containers. Most notably is the certificate maintenance. Until the controller will roll its own server cert (if it ever does), one thing the 'deployment' containers will do for you is roll that cert over on restart of the container. That makes it a bit easier on you when your server cert expires and you need to roll it over. It's not a huge hassle, maybe you prefer to roll it yourself, but that might be one reason to use the "deployment" container.

Whichever way you go, we'll be here to help you out. :slight_smile: GLHF

1 Like

Thank again, much appreciated... Noted on the cert considerations.

A couple of other thoughts/questions that I've been pondering through my ziti daydreaming such far...

Is it correct that soon we will be able to some type of external auth like oidc/oauth to Entra for example, and use this for end users on the common windows/mac/mobile edge clients? Or is this already possible? Are the clients able to launch a web browser for external auth to allow them to enter their entra credential for example?

In regards to the initial add identity / enroll client process from an end users perspective - what is the common practice here? Is there a portion of ZAC that can exposed to users to allow them to add themselves and download the .JWT? And in the case of the external auth in the above paragraph, this initial enroll process I'm thinking still remains with the oauth/oidc process to the external IDP occuring as part of the MFA check?

Yes, it's being worked on. The latest pre release of the ziti desktop edge for Windows (zdew) has support and we are adding it to macOS currently. I believe iOS will get support for it as well, but I'm not :100: on that just yet. I think it'll come to android/iOS but I'm not sure.

Yes with all the same caveats as mentioned above. I plan to do a ziti tv / video on this functionality for zdew after break. I'm in the midst of documenting it. If you want to preview that doc, it'll be here External Provider - JWT | OpenZiti (there's more on the left nav but it's all related)

Expand the "Example Configuring OpenZiti for External Auth" section at External Providers | OpenZiti

I didn't quite understand. I think if you check out that doc preview it'll likely/hopefully answer your question?

Actually you probably want the "Obtaining the Network JWT" section for that one question from External Provider - JWT | OpenZiti