Configuring ZTNA Scenario for Selective Domain

I'm working on a ZTNA scenario where only specific domains (Google, LMS, and YouTube) should be accessible, while all other domains remain blocked. Below are the commands I used for configuration:

ziti edge create config google-intercept intercept.v1 '{"protocols":["tcp"],"addresses":["www.google.com"],"portRanges":[{"low":443,"high":443}]}'
ziti edge create service google-service --configs google-intercept
ziti edge create config lms-intercept intercept.v1 '{"protocols":["tcp"],"addresses":["lms.telkomuniversity.ac.id"],"portRanges":[{"low":443,"high":443}]}'
ziti edge create service lms-service --configs lms-intercept
ziti edge create config youtube-intercept intercept.v1 '{"protocols":["tcp"],"addresses":["www.youtube.com"],"portRanges":[{"low":443,"high":443}]}'
ziti edge create service youtube-service --configs youtube-intercept
ziti edge create service-policy google-bind-policy Bind --service-roles "@google-service" --identity-roles "@test-laptop"
ziti edge create service-policy google-dial-policy Dial --service-roles "@google-service" --identity-roles "@test-laptop"

ziti edge create service-policy lms-bind-policy Bind --service-roles "@lms-service" --identity-roles "@test-laptop"
ziti edge create service-policy lms-dial-policy Dial --service-roles "@lms-service" --identity-roles "@test-laptop"

ziti edge create service-policy youtube-bind-policy Bind --service-roles "@youtube-service" --identity-roles "@test-laptop"
ziti edge create service-policy youtube-dial-policy Dial --service-roles "@youtube-service" --identity-roles "@test-laptop"

Although I expected only these three domains to be accessible, I have whitelisted all three domains in the configuration, so I’m not sure why three of them remain inaccessible.

Hi @garry0, OpenZiti operates in a fully split tunnel mode and it doesn't really try to be a firewall nor does it have many (any?) firewall related features. Approve-listing a service will mean that the specific address you added to the intercept will be intercepted, but all other traffic will traverse your network as though OpenZiti were not running at all. that means all the other traffic will go to your default gateway and get routed from there.

OpenZiti also operates on allow lists only - it extends/adds access, it doesn't take it away. There's no way to make a deny list functionality with OpenZiti that I can think of. Instead, you have to block all the "non-OpenZiti" traffic using your underlay network.

Hope that helps

Thank you for the explanation. It clarifies the limitations with OpenZiti in terms of blocking non-approved traffic directly. I understand now that OpenZiti's allow list approach means that any traffic not intercepted by OpenZiti will simply route through the default network path, without enforcing restrictions.

Given this, I'm curious—what kind of scenario might you recommend to explore this ZTNA concept further? Ideally, I’d like to experiment with a setup that still aligns with the "Zero Trust" model and enforces access only to specific services.

Zero trust doesn't mean there's no internet access and there aren't "untrusted" network segments. It's not about blocking all network traffic other than explicitly trusted connections though I can understand how one might have that thought.

Generally speaking, zero trust will require the provider of the service to implement the zero trust functionality so services like Google/YouTube etc aren't ones I would associate with zero trust. those are explicitly public services and don't have any expectation of trust.

So if we can agree that zero trust starts with the service -- and neither you nor I are provisioning the "server" source, those can't be considered in a zero trust environment. Instead, let's focus on providing our own services in a zero trust fashion. For example NetFoundry hosts its own Mattermost server for chat communication. We protect this service which we host ourselves with OpenZiti. Our employees (or contractors or whomever) who want to chat on our internal chat server must have an identity on the appropriate OpenZiti overlay network. Without the identity, we can't chat with one another. But this is a self-hosted service. We wouldn't use OpenZiti with the cloud-based version of slack for example, it's the self-hosted Mattermost that it makes sense.

That clear anything up? Or just confuse you more? :slight_smile:

I got it! Now I have a much clearer understanding that Zero Trust is not about restricting all traffic, but rather about implementing proper trust verification for services we control and manage.

Also, I was looking at the OpenZiti documentation, specifically the "Your First Service - Zero Trust Host Access" section. If I'm not mistaken, this tutorial demonstrates exactly what you're explaining - it shows how to set up Zero Trust access for an internal service (SSH access to a host), right? Would following and expanding upon this kind of scenario be a better starting point for learning Zero Trust implementation with OpenZiti?

2 Likes

Exactly. You got it!

The "Your First Service" page will actually demonstrate sort of what you were going after with YouTube/Google... It doesn't setup ssh, it sets up "some silly HTTP server". An HTTP-based example is an incredibly common "first service" but you can absolutely use OpenZiti for ssh! In fact, we here at NetFoundry do exactly that, you cannot even ssh to our production instances without having an authorized idenitity on the proper OpenZIti overlay.

Both of those examples, either ssh or HTTP are great "first examples" though, yes. They are both very common uses of OpenZIti. There are YouTube videos that walk through these scenarios too, if you've not found/seen them they might help by adding extra context. (some people prefer to read, some prefer to 'do', some like to watch, some like all three)

Have fun! :slight_smile: