Are there many big installations of it? With the vast majority of stuff being written for regular networks I do wonder if the amount of proxies/sidecars becomes unreasonable. Probably not though
So we have not finished our job to make OpenZiti the equivalent to Linux in that every just uses it by default, but we will get there ;)
You raise an interesting point. We provide flexibility for ingress/egress... do not like proxies/sidecars, go in either opposite direction, (1) ZTAA, Zero Trust App access with SDK app embedded via SDLC, (2) ZTNA, Zero Trust Network Access via appliance deployments in DMZ/VP/VNET etc (the one you mention is ZTHA, Host Access). Each of ZTNA/HA/AA have different pros and cons based on your requirements and use case.
This one is the most compelling to me! A while back I was building a small cloud provider and this was the use case I was looking really closely at OpenZiti for.
Thanks for sharing!
>You raise an interesting point. We provide flexibility for ingress/egress... do not like proxies/sidecars, go in either opposite direction, (1) ZTAA, Zero Trust App access with SDK app embedded via SDLC, (2) ZTNA, Zero Trust Network Access via appliance deployments in DMZ/VP/VNET etc (the one you mention is ZTHA, Host Access). Each of ZTNA/HA/AA have different pros and cons based on your requirements and use case.
Ah so this would work if:
1) all the apps were my own
2) I was sitting on top of a major cloud/managed colo (I'm just sitting on top of infra providers like hetzner)
The project I was working on is not so active right now but it's still chugging along (I use it)... I was looking at things like OpenZiti as a k8s CNI provider, or used along with something like Cilium/Calico (but then they'd both promise network security in-between workloads and overlap)
Yes, OpenZiti very much focus on private apps, whether COTS or inhouse developed.
Oh, I should note too, while we have a bunch of ways to deploy OpenZiti on K8S today, we are in the process of building/releasing an admission controller and an ingress controller for OpenZiti.
Whats the project you work on?
Yeah Istio is a hard no for me... And yeah I definitely appreciate that OpenZiti does a lot more than service meshes do! I personally try to avoid service meshes (if I were to use one, I'd go with linkerd).
I'm just not convinced that many people need a service mesh -- I haven't really needed one yet, but maybe I'm just not at the right scale/etc.
> Oh, I should note too, while we have a bunch of ways to deploy OpenZiti on K8S today, we are in the process of building/releasing an admission controller and an ingress controller for OpenZiti.
This is awesome -- I really like my current admission controller though (Traefik), it's FANTASTIC. I think moving ingress controllers might be a large lift for people (it would be for me).
> Whats the project you work on?
I don't really work on it actively these days (haven't in a while) but https://nimbusws.com
Looking forward to picking it back up more actively in the future though, for now I use it for some small background services.
I get that. Would need to check if we can integrate Ziti into Traefik in the same way we did for Nginx (https://blog.openziti.io/nginx-zerotrust-api-security) and Caddy (https://blog.openziti.io/put-some-ziti-in-your-caddy), which we did respectively using the C and Golang SDKs. Therefore you wouldn't need to change your ingress, you would just load Ziti as a module in it.
Yeah, this is why I was thinking that the easiest way to integrate would be a sidecar (and in general for random web serving payloads). I'm not ruling it out, but this was the major stopper -- it seemed easier to just rely on Cilium/Calico underneath to keep east-west comms encrypted between apps and k8s nodes.
Clarification: You could use Traefik's ingress controller in tandem with a hypothetical OpenZiti ingress controller. You'd set `ingressClass: openziti` on those Ingress resources you wish OpenZiti to handle. Nothing would prevent you from creating two Ingress resources for the same ClusterIP service: one each for Traefik and OpenZiti.
That's cool, I did that for an HTTP forwarding thing a while back.
"Now, your server has no listening ports on the underlay network. It's literally unattackable via conventional IP-based tooling. Seriously, stop and consider that for just a moment. By adopting an OpenZiti SDK into the server, all conventional network threats are immediately useless."
It's a tradeoff between in-process and out-of-process though. It's nice that Firezone Gateways don't have access to the service's memory space and can't crash the process, but it's also nice that an in-process Gateway equivalent doesn't need to loop through the network to reach its service.
Do they support this?
I hear you on having 'out of process', that's why OpenZiti also has tunnellers for deploying on host as well as virtual appliances to run in the DMZ/VNET/VPC etc. I was only aware of Firezone supporting those 2 deployment models.