Hacker News Reader

Comment by concerndc1tizen | Hacker News Reader

Sounds amazing and like it addresses my issues with Nebula. I know that Nebula/Defined Networks was/is working on better Kubernetes integration, but it seems unlikely to become generally available. Is that something you're supporting? i.e. as pod sidecar to authenticate services like nebula has ACL.

What's your funding model? Are enterprises willing to sponsor the development?

I think Nebula has a lot of trust solely because it's made at/used by Slack. In a similar sense, why should enterprises trust OpenZiti? If services do not use e2ee (e.g. service mesh with TLS) but rely on OpenZiti, it places a lot of trust in OpenZiti. How has the code been audited? Why are you confident that it's cryptographic implementation is secure?

View on HN

OpenZiti is developed and maintained by NetFoundry (https://netfoundry.io/). We provide a productised version which is very easy to deploy, manage, operate, and monitor with high SLAs, support, legal/compliance, liability, security, updates, feature requests etc.

We are not rolling our own crypto, we use well vetted open source standards/implementations - https://openziti.io/docs/learn/core-concepts/security/connec.... If you don't trust that, you can easily roll your own - https://github.com/openziti/tlsuv/blob/main/README.md. I know people who do that. Yes, its been audited, and run my many large enterprises in security conscious use cases - e.g., 8 of the 10 largest banks, some of the largest defence contractors, leaders in ICS/OT automation as well as grid etc.

Yes, we support K8S in a lot of ways, both for tunnelling and deployement - https://openziti.io/docs/reference/tunnelers/kubernetes/. There are more native options being worked on incl. Admission Controller and Ingress Controller but I honestly don't know the exact status of either. If they interest you, feel free to ping me on philip.griffiths@netfoundry.io. I can get more info.

Sounds great. It puzzles me that Nebula hasn't done what you're doing with OpenZiti.

In my opinion, Kubernetes networking is flawed, in that service mesh authentication with mTLS has unnecessary overhead, Cilium network policies are clumsy using labels and work poorly with non-pod workloads (i.e. CIDR-based policies), multi-cluster is hacky, and external workloads are inconvenient to set up. So a simple plug-and-play solution that solves these problems would be great.

My guess is that is how they want to commercialise, they make that bit harder so that more people pay for their hosted solution. I have sympathy, monetisation allowing maintaining FOSS can be a challenge. We all have bills.

I agree with a lot of what you say. Tbh, this is also why we are advocates of app-embedded ZTNA. You get mTLS (and way, way more) out of the box, without the overhead, and its super easy to run your K8S or non-K8s workloads anywhere. No need for VPNs, inbound FW ports, complex ACLs, L4 loadbalancers, public DNS and more. It is thus much easier to build distributed systems which are secure by default from network attacks.

You comment kicked off a big internal chat, which led to someone creating a document on our overlay approach, vs service meshes. I took that, wrote some extra details, comparison and summary - https://docs.google.com/document/d/1ih-kuRvfiGrJODZ5zVjwFLC2....

TL:DR, we believe service meshes introduce complexity with control plane synchronization, service discovery challenges, and network overlays. A Global Overlay removes Kubernetes service dependencies and shifting networking to a Zero Trust, software-defined global overlay which is much simpler, automated and secure.

Super curious to get your thoughts.

Couple of additional small notes (maintainer here)

> In a similar sense, why should enterprises trust OpenZiti?

you don't have to. It's open source - so you go look at all the code and judge for yourself but perhaps better than that (well different anyway) is that OpenZiti allows you to use your own PKI for identities if youlike. With third-party CA support, you can make your own key/cert and deploy them to identities if you desire. https://openziti.io/docs/learn/core-concepts/pki/#third-part...

> If services do not use e2ee

with OpenZiti you basically get this by default between OpenZiti clients. (once offloaded from the OpenZiti overlay, it's up to the underlying transport protocol)

Reply on news.ycombinator.com