As I wrote in a previous poste, the BIND USING EDGE IDENTITY option helped me to move forward, but now that we are planning to build the target organization, I’m a bit lost on the way to achieve it. Could you please advise me on the best settings?
The most important thing to notice is that each group is independent and must not be able to communicate with other groups otherwise it would be a serious security breach.
Authorized requests are:
inside each group: clients to group servers (blue arrows
outside groups:
group servers to main servers (green arrows)
clients to main server (orange arrows)
Actually, I would have loved to be able to add request from the main server to group servers and from group servers to group clients but I think it’s technically impossible.
The numbers noticed are very important and that’s my problem: I don’t know how to build the configs / services / policies to achieve this without a huge amount of work and a huge load on the controller. I would avoid to create hundreds or thousands of rules. I guess that good technical choices could optimize the whole management but I’m not sure on the best way to do this.
Last thing: we currently use the same destination port for all the sessions described above but it would not be a problem to use different ports if needed.
I hope my explanations make sense and you can give me good advices to move forward.
Hi, I think it’s possible to do what you’re looking for with OpenZiti service policies. Basically you create service-policies that are associated with roles, and you assign roles to the identities that are allowed to dial or bind the service.
We’re definitely not talking about a “tunneler issue” at this point though, so could you please start a new thread with the info from your previous post here and maybe include the configs for the service(s) that you want to share between the groups?
When I look at this diagram, one service to connect to the "main server" clearly stands out to me and would be very easy to implement. That's one service that all identities have dial access to.
Each "group" seems like it might be a bit more cumbersome. For those, each "group client" would dial a "group server" service. That's somethign you'd probably want to automate just because there are hundreds of them but i would do that with #group1-binders, #group1-dialers approach if it were me. Then each client would get the group-dialer attribute and each server would get the group-binder attribute and then each client could dial the appropriate server.
My initial thought (as you could see above) makes me think you can't. I don't think there's any fancier way than basically "2 rules per group". Maybe there is, but it's not coming to my mind at this time. Still that's "only" hundreds and should be fine (other than being cumbersome, hence automation).
If you are using short lived HTTP requests only, you COULD do this with OpenZiti but you'll have to add more services, dial by identity etc. However if you use something like a websocket or any persistent type of connection or using HTTP long-polling, server sent events etc, well at that point your servers COULD connect back to the clients or your main server to the group servers through that persistent connection. So I don't think it's impossible at all if you go that route. If you don't want the clients to have to initiate that connection, you can still do it but you'll end up with more OpenZiti rules to manage and maintain. I would probably change the attributes then to just @group1-client and @group1-server and give clients the ability to dial servers and servers the ability to dial clients and then make appropriate services.
Totally agree with Clint’s take. One thought that occurs to me in addition, NetFoundry supports a SCIM functionality where you can auto-provision identities and sync IdP groups → role attributes, so the only thing you’re “creating hundreds of” is done by the IdP + API/templates, not by hand.
This trims toil (and drift) but doesn’t remove the per-group policy pattern into one “magic” rule.
I'm moving forward with my case. There is something I did not mention and that might be cumbersome: we don't know in advance the underlay IP addresses for the servers and clients in the groups. They are installed at customers' sites with existing network settings we can't change.
In the host.v1 config, we can use BIND USING EDGE IDENTITY and this is very useful. But in the intercept.v1 config, what am I supposed to put? I saw this example on the forum:
{
"addresses": [
"acme.ziti",
"*.dazzle.acme.ziti",
"10.0.0.0/8"
],
"portRanges": [
{
"low": 1025,
"high": 1999
}
],
"protocols": [
"tcp"
]
}
and I tried to put "0.0.0.0/0" as addresses but it does not work. Is there a way to tell "any address" to the tunneler? Or do you advise to create an intercept config for each group that mentions the identities of all servers in the group? As performance will be a challenge, what should be the best solution to your point of view?
Do you mean the TARGET IPs? Or do you mean the actual machine IPs? The machine IP address don't matter at all. As for the target IPs, my advice would be "don't use IPs, use DNS". That way you can just make one ziti service "the.target.dns" and whatever IP at the client address it'll get resolved.
If you can't do that, well then it'll definitely be a bit more automation that's needed I think. I don't think there's any magic you could do to figure that out.
Some of what you describe sounds like an IP range. What some people do is define an intercept that says: "Intercept any 192.168.0.0/16 IP address". Then at the far side you can use the "forward *" options: forward port, forward protocol, forward IP.
Then at the client if they type in 192.168.10.10 on the far side a connection would be made to 192.168.10.10.
That help? The way you have formulated the question, I'm not on what you're asking and the scenario. I don't think this number of rules will be a performance challenge. Our zrok installation has 10's of thousands of rules (it's properly sized of course).
on what you're asking and the scenario. I don't think this number of rules will be a performance challenge. Our zrok installation has 10's of thousands of rules (it's properly sized of course).