Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Launch HN: Firezone (YC W22) – Zero-trust access platform built on WireGuard

news.ycombinator.com

Post reply on HN
Print view View original

71–80 of 90 posts

Re: Launch HN: Firezone (YC W22) – Zero-trust access platform built on WireGuard

#71

Post by hardwaresofton »

PLG88 wrote: post #69
hardwaresofton wrote: post #68

Earlier quoted context omitted.

> A hyperscaler is adopting it to replace hundreds of thousands of VPNs as well as build a multi-cloud zero trust offering for server to server workloads. 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 no…

You could use OpenZiti together with Cilium/Calico, there are some distros, eg., https://kubezt.com/ which do that (though in truth, KubeZT has moved to Istio for E-W, uses OpenZiti for N-S. OpenZiti does a lot of things that service mesh technologies do not, for example, extending outside of the cluster (incl. to non-K8S workloads), allowing closing of inbound FW ports, providing a private DNS outside of cluster, re…

> You could use OpenZiti together with Cilium/Calico, there are some distros, eg., https://kubezt.com/ which do that (though in truth, KubeZT has moved to Istio for E-W, uses OpenZiti for N-S. OpenZiti does a lot of things that service mesh technologies do not, for example, extending outside of the cluster (incl. to non-K8S workloads), allowing closing of inbound FW ports, providing a private DNS outside of cluster, removing the need for VPNs, L4 loadbalancers, MPLS, SDWAN, public DNS etc.

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.

Re: Launch HN: Firezone (YC W22) – Zero-trust access platform built on WireGuard

#72

Post by PLG88 »

hardwaresofton wrote: post #71
PLG88 wrote: post #69

Earlier quoted context omitted.

You could use OpenZiti together with Cilium/Calico, there are some distros, eg., https://kubezt.com/ which do that (though in truth, KubeZT has moved to Istio for E-W, uses OpenZiti for N-S. OpenZiti does a lot of things that service mesh technologies do not, for example, extending outside of the cluster (incl. to non-K8S workloads), allowing closing of inbound FW ports, providing a private DNS outside of cluster, re…

> You could use OpenZiti together with Cilium/Calico, there are some distros, eg., https://kubezt.com/ which do that (though in truth, KubeZT has moved to Istio for E-W, uses OpenZiti for N-S. OpenZiti does a lot of things that service mesh technologies do not, for example, extending outside of the cluster (incl. to non-K8S workloads), allowing closing of inbound FW ports, providing a private DNS outside of cluster,…

Ahh, thats cool. Note, the app embedded capabilities of OpenZiti becomes very interesting in this scenario, for example, our Python SDK working with Boto3 for AWS S3 - https://blog.openziti.io/extend-access-to-a-private-s3-bucke....

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.

Re: Launch HN: Firezone (YC W22) – Zero-trust access platform built on WireGuard

#73

Post by PLG88 »

nmadden wrote: post #70
PLG88 wrote: post #66

Earlier quoted context omitted.

The idea of “zero trust appliances” is that you can reduce the attack surface from the external network, that is how Zscaler positions it, to make you apps 'dark'. IMHO though, the logical conclusion is to give every application, as part of the software development lifecycle its own private network, which implements zero trust principles - least privilege, microsegmentation, default deny, strong identity, device auth…

But a simple gateway/ELB can protect your apps from the public internet. (But unless you’re pushing a root CA cert to all client devices then those apps aren’t “dark” in any sense due to CT logs). Zscalar’s ZPA docs say: > [ZPA] mitigates lateral threat movement through advanced segmentation https://www.zscaler.com/products/zscaler-private-access So it must be doing some segmentation at the network level, otherwise w…

The gateway/ELB has inbound ports and 'listens' on the WAN interface for incoming connections. Therefore it can be subject to external network attacks, and be compromised if a CVE etc exists.

Zscaler Private Access makes outbound connections so that you can deny all inbound connections and not be subject to external network attacks. It also creates application-specific connections, rather than a full tunnel so that each connection is inherently microsegemented and inaccessible to anything outside of that tunnel.

We do the same thing on the open source project I work on, OpenZiti (https://github.com/openziti), though our platform is more like ZPA on steroids.

Re: Launch HN: Firezone (YC W22) – Zero-trust access platform built on WireGuard

#74

Post by hardwaresofton »

PLG88 wrote: post #72
hardwaresofton wrote: post #71

Earlier quoted context omitted.

> You could use OpenZiti together with Cilium/Calico, there are some distros, eg., https://kubezt.com/ which do that (though in truth, KubeZT has moved to Istio for E-W, uses OpenZiti for N-S. OpenZiti does a lot of things that service mesh technologies do not, for example, extending outside of the cluster (incl. to non-K8S workloads), allowing closing of inbound FW ports, providing a private DNS outside of cluster,…

Ahh, thats cool. Note, the app embedded capabilities of OpenZiti becomes very interesting in this scenario, for example, our Python SDK working with Boto3 for AWS S3 - https://blog.openziti.io/extend-access-to-a-private-s3-bucke... . 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.…

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

Re: Launch HN: Firezone (YC W22) – Zero-trust access platform built on WireGuard

#75

Post by nmadden »

PLG88 wrote: post #73
nmadden wrote: post #70

Earlier quoted context omitted.

But a simple gateway/ELB can protect your apps from the public internet. (But unless you’re pushing a root CA cert to all client devices then those apps aren’t “dark” in any sense due to CT logs). Zscalar’s ZPA docs say: > [ZPA] mitigates lateral threat movement through advanced segmentation https://www.zscaler.com/products/zscaler-private-access So it must be doing some segmentation at the network level, otherwise w…

The gateway/ELB has inbound ports and 'listens' on the WAN interface for incoming connections. Therefore it can be subject to external network attacks, and be compromised if a CVE etc exists. Zscaler Private Access makes outbound connections so that you can deny all inbound connections and not be subject to external network attacks. It also creates application-specific connections, rather than a full tunnel so that e…

The Zscaler exchange also listens to incoming connections, as does the OpenZiti edge router. How is this different? I’ve just swapped one vendor’s edge appliance (eg AWS ELB) for another. A CVE in either has the same impact, no?

Application specific connections are great and everything. But if a web app has a log4shell-like vulnerability then that app-specific connection means nothing if the app isn’t also isolated at the network level to prevent lateral movement.

PS - denying incoming connections doesn’t eliminate all network attacks by any means.

Re: Launch HN: Firezone (YC W22) – Zero-trust access platform built on WireGuard

#76

Post by PLG88 »

nmadden wrote: post #75
PLG88 wrote: post #73

Earlier quoted context omitted.

The gateway/ELB has inbound ports and 'listens' on the WAN interface for incoming connections. Therefore it can be subject to external network attacks, and be compromised if a CVE etc exists. Zscaler Private Access makes outbound connections so that you can deny all inbound connections and not be subject to external network attacks. It also creates application-specific connections, rather than a full tunnel so that e…

The Zscaler exchange also listens to incoming connections, as does the OpenZiti edge router. How is this different? I’ve just swapped one vendor’s edge appliance (eg AWS ELB) for another. A CVE in either has the same impact, no? Application specific connections are great and everything. But if a web app has a log4shell-like vulnerability then that app-specific connection means nothing if the app isn’t also isolated a…

I cannot speak for Zscaler in this scenario, but I can explain why its different and reduced risk for OpenZiti/NetFoundry (I literally posted on this topic yesterday on LN, blog post coming soon - https://www.linkedin.com/posts/philipleonardgriffiths_no-lis...)

First things first. Yes. If a vulnerability exists in the overlay network that would allow an attacker to bypass the security of the zero trust network, but what does that mean in practice? Well, to do this they would need to: - (1) need to bypass the mTLS requirement necessary to connect to the data plane (note, each hope is uses its own mTLS with its own, separate key). - (2) have a strong identity that authorizes them to connect to the remote service in question (or bypass the authentication layer the controller provides through exploits; note again, each app uses separate and distinct E2EE, routing, and keys) - (3) know what the remote service name is, allowing the data to target the correct service (not easy as OpenZiti has its own private DNS that does not need to comply to TLDs) - (4) bypass whatever "application layer" security is also applied at the service (ssh, https, oauth, whatever) - (5) know how to negotiate the end to end encrypted tunnel to the 'far' identity

So yes, if they can do all that, then they'd definitely be able to attack that remote service.

But wait, I said "remote service", not "remote services". Thats right, all that work and compromises and they only have access to 1 single service among hundreds, thousands, or potentially millions of services. Lateral movement is almost mpossible. So the attacker would have to repeat each of the 5 steps for every service.

Finally, how would they know which company sits behind which OpenZiti fabric. Thats right, they don't. So its pot luck if its even against the target they want to try and exploit.

Re: Launch HN: Firezone (YC W22) – Zero-trust access platform built on WireGuard

#77

Post by PLG88 »

PLG88 wrote: post #76
nmadden wrote: post #75

Earlier quoted context omitted.

The Zscaler exchange also listens to incoming connections, as does the OpenZiti edge router. How is this different? I’ve just swapped one vendor’s edge appliance (eg AWS ELB) for another. A CVE in either has the same impact, no? Application specific connections are great and everything. But if a web app has a log4shell-like vulnerability then that app-specific connection means nothing if the app isn’t also isolated a…

I cannot speak for Zscaler in this scenario, but I can explain why its different and reduced risk for OpenZiti/NetFoundry (I literally posted on this topic yesterday on LN, blog post coming soon - https://www.linkedin.com/posts/philipleonardgriffiths_no-lis... ) First things first. Yes. If a vulnerability exists in the overlay network that would allow an attacker to bypass the security of the zero trust network, but…

p.s., app embedded makes network attacks almost impossible as you no longer have a listening port on the underlay network, well described here - https://blog.openziti.io/go-is-amazing-for-zero-trust

Re: Launch HN: Firezone (YC W22) – Zero-trust access platform built on WireGuard

#78

Post by illumiN8i »

jkelleyrtp wrote: post #12

Hey! I worked on WARP at Cloudflare. I believe Cisco has anyconnect and then there's zscaler. I'm curious how you guys are competing with the other folks in the space. WARP was/is a really tough product to maintain (crossplatform networking is very difficult). CF was doing well with WARP mostly due to the distribution advantage. I imagine it's harder for startups to break into the space.

As a WARP user that has experienced a lot of problems, I'm glad that Cloudflare is allowing WARP users to switch from wireguard to MASQUE. I'm hopeful this will solve a lot of our issues.

Re: Launch HN: Firezone (YC W22) – Zero-trust access platform built on WireGuard

#79

Post by RsmFz »

illumiN8i wrote: post #78
jkelleyrtp wrote: post #12

Hey! I worked on WARP at Cloudflare. I believe Cisco has anyconnect and then there's zscaler. I'm curious how you guys are competing with the other folks in the space. WARP was/is a really tough product to maintain (crossplatform networking is very difficult). CF was doing well with WARP mostly due to the distribution advantage. I imagine it's harder for startups to break into the space.

As a WARP user that has experienced a lot of problems, I'm glad that Cloudflare is allowing WARP users to switch from wireguard to MASQUE. I'm hopeful this will solve a lot of our issues.

Hm, is Wireguard getting blocked by middleboxes or something?

Re: Launch HN: Firezone (YC W22) – Zero-trust access platform built on WireGuard

#80

Post by RsmFz »

PLG88 wrote: post #39
jkelleyrtp wrote: post #12

Hey! I worked on WARP at Cloudflare. I believe Cisco has anyconnect and then there's zscaler. I'm curious how you guys are competing with the other folks in the space. WARP was/is a really tough product to maintain (crossplatform networking is very difficult). CF was doing well with WARP mostly due to the distribution advantage. I imagine it's harder for startups to break into the space.

Through OpenZiti into the mix too - https://openziti.io/ . Its open source and was designed from the ground up with zero trust, SDN, and deny-by-default principles. It also includes SDKs to allow developers to embed ZTN as part of the SDLC. We also built zrok ( https://zrok.io/ ) on top of it, as a demonstration of a 'ziti-native' app, and being a better Ngrok.

Oh so that allows it to run in-process?

That's cool, I did that for an HTTP forwarding thing a while back.

Post reply on HN