Want to know more about Ziti concepts

Support General Questions
1

Hi Team,
I have read through | Ziti documentation and it really helped a lot in understanding ziti’s concepts.
Post deployment of the quickstart network and ZAC along with it, i found more new stuff on ZAC.
Sections like Configurations, Terminators, Config Schema, Transit Routers. For these topics i couldn’t find much with documentation. Could you please care to explain these topics or direct me to ziti.tv or youtube link explaining in detail about these and most importantly about its value add.

Secondly i have a questions:
I didn’t get much clarity that do we need both service policy with Bind and Service Edge router policy at the same time ?
In the typical example of deployment (using docker-compose), ziti-private-blue edge router would serve applications launched within its network. In this example its a web server. My question is, Do we need both service bind policy (Binding app with ER Identity) and Service Edge router policy (mapping a service with ER) ?
What is the difference between both of them and which one is used in which usecase ?

Thanks

1 Like
2

Configs are important. You don't need a config if you are doing app-embeded openziti but they are there for you. It's basically a mechanism to add some metadata to your service.

Terminators are important but - in my experience - I never use them. I consider them an 'advanced' usage of OpenZiti and I'd recommend you get your feet really well established with OpenZiti before digging in there too too much. :slight_smile:

Config Schema define configs. Configs are "instances" of some schema. You must declare a Config Schema in order to make a config. There are 5 configs we deploy with OpenZiti because our tunneling apps use/need them. Tunneling apps are, after all, just SDK apps. The configs are used to infofrm the intercepting tunneller what to intercept and how, and the 'server' client how to offload that traffic...

Transit Routers are routers that are not 'edge enabled'. You would deploy them to build up your mesh network bigger and provide more pathing to OpenZiti to get you to the destination faster. Also something i would say is "advanced use" of OpenZiti and it's worth getting your OpenZiti feet under you before playing with this.

These are the same question really. and YES. You MUST have a "dial" and "bind" policy somehow for every single edge-sdk service. This is easy to understand though. In a zero trust overlay network like OpenZiti you are authorizing identities. There's an identity on both sides of your connection the initiating side (often referred to as the client) and the receiving side (often referred to as the server)

You make a 'Bind' policy to authorize an identity has the ability to host/bind a service. This would be your 'server'.

You make a 'Dial' policy to authorize an identity to access the service (or dial). This would be the 'client'.

I actually just wrote up a crazy quick guide to using the golang sdk example for zitified http client/server here. You can see the last two lines are about making the bind/dial service-policies.

Hope that helps :slight_smile:

3

Hi Clint,
I have few basic questions:

  1. From the docker-compose example, how does the traffic flow happens in blue network once a tunneller is launched within.

This is my understanding, please correct me here if i am wrong:

The blue network consists of private ER (ziti-private-blue), which connects with ziti-edge-router (simulated public edge router). Ziti-edge-router helps in onboarding the traffic (application) from the private network via ziti-private-blue). Here the ziti-private-blue is ONLY used for the purpose of routing. So once the tunneller is launched which acts as an proxy to the application, will forward the traffic towards ziti-private-blue ER. Then the same gets forwarded and onboarded to openziti ZTN via ziti-edge-router.

  1. What is the purpose and functionality of having ziti-fabric-router-br & ziti-edge-router-wss (web socket service) ? Are they mandatory ?

  2. Can’t the ziti-private-blue & ziti-private-red have tunneller (proxying) capabilities to avoid deploying an additional tunneller all together ?

4

I attached the ziti-edge-tunnel just to emulate "some other machine" on that 'blue' network. Basically that ziti-edge-tunnel will connect to any configured Edge Router in your overlay. In the docker-compose quickstart, that's only going to be the one "ziti-edge-router" container. That will provide access into the 'blue' network from that identity.

Your question #3 touches on this topic too - can't the same be done without the ziti-edge-tunnel by using the router deployed into the blue / red network with "tunneler" mode activated on it. That works with the edge enabled, yes. Just change the docker-compose file you start by updating two lines in the compose file so that ziti-private-red and ziti-private-blue use edge not private:

command: "/openziti/scripts/run-router.sh edge"

instead of what is currently there:

command: "/openziti/scripts/run-router.sh private"

Realistically "nothing" yet. The idea is to just illustrate the concept that OpenZiti is a full mesh and there are routers which are not used for 'edge' and are just used for transit. The idea in my head is to some day tune the paths in the fabric and steer/shape traffic accordingly. I don't have any doc on doing that yet so - totally not needed.

The wss one is to support an upcoming (and exciting) thing we call browzer. Browzer provides zero trust connectivity into your browser without needing to install a plugin. You can watch the Youtube channel for @curt posting about browzer but - for now you don't need that either...

The 'simplest' compose file is actually https://github.com/openziti/ziti/blob/release-next/quickstart/docker/simplified-docker-compose.yml . This is nothing more than just controller, one edge router, and ZAC. I tend to deploy the "non-simplified" one just because I like having the extra networks, routers to play with... :slight_smile: