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.
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