there is at least one community-managed flake to connect a NixOS machine to an OpenZiti overlay network, but i don't think there is an official NixOS module yet:
github.com/rochecompaan/openziti-nix
if your focus is trying it rather than distributing consistent versions to many folks, you can also use the ziti-edge-tunnel binary, define a systemd service and add identities (a given app or device can belong to (n) OpenZiti overlays via (n) different identities).
>Claude will be able to leverage these capabilities to extend its reach across the cloud and add more value in enterprise use cases
100%. even more robust if paired with an overlay network which provides identity based s3 access (rather than ip address/network based). else server may not have access to s3/cloud resource, at least for many enterprises with s3 behind vpn/direct connect.
ditto for cases when want agent/client side to hit s3 directly, bypassing the server, and agent/client may not have permitted IP in FW ACL, or be on vpn/wan.
2. Performance and reliability. 100+ PoPs in all major clouds running their data plane routers if they host (still E2EE), or run routers anywhere if you self-host. Dynamic routing to find best paths across the routers.
I don't see any indication that NetFoundry zrok supports end-to-end encryption from the client to the web server. The default configuration definitely terminates SSL on NetFoundry's server, and I don't see any documentation for how to avoid that. There's a TCP tunneling mode, but servers that use this mode can only be accessed by clients that are themselves also connected to the NetFoundry VPN service, not by clients on the public web. What's needed is a TLS tunneling mode that figures out the correct target via SNI, and zrok doesn't seem to provide that.
You are correct, zrok doesn't support mutual TLS. zrok is the free offering that NetFoundry supports so it's easy to see why you looked there for information.
> It'll still terminate TLS at the servers, though. It's not mTLS all the way
> through to the endpoint.
That was the entire point, though. If NetFoundry Frontdoor can see the traffic (because it gets terminated on their servers, mTLS or not), then it's not end-to-end encrypted as the parent commenter claimed.
I think the issue is zrok vs. NetFoundry/OpenZiti. Zrok is the easy button to project a public endpoint from inside a network. It is not encrypted all the way through, as it is a proxy solution. NetFoundry/OpenZiti provides methods to provide tunnels all the way through. NetFoundry is a company, OpenZiti is a FOSS project/technology sponsored by NetFoundry, and zrok is a product of NetFoundry built on OpenZiti tech, so it is easy to cross things up. I think the comment was in regard to NetFoundry/OpenZiti, while your response referenced zrok. The list above has both.
>nobody makes money when things aren't locked down
i would rephrase as "incumbents don't usually make more money if things are opened up".
if consumer gets materially better value, then challenger ecosystem around MCP will evolve. it will be open at first - great for startups and challengers, innovator's dilemma for market leaders.
and then it will close as the new wave establishes their moats. but, similar to web, even though the current web leaders are now much more closed than we would like, the overall ecosystem is more open than it was.
Top cybersecurity VCs supporting open source model? Check.
Yes, it is possible to make the world a more secure place by helping both the open source community and the world's largest companies. Arguably, it is the best way.
And, no, we did not change our licensing. Apache 2.0, purposefully permissive.
We need to be careful on how and where we define our constraints regardless, but we can mitigate against this to some degree for some APIs:
>The problem with these increasingly expressive end points is that you are putting them not just in the hands of your front end developers, but also in the hands of potentially hostile users.
Meaning, let's not expose to 'hostile users' if we can help it.
For example, put the API gateway solely on a private overlay, and gate entrance to that overlay to endpoints with enrolled private key signed certs (+ other factors if you wish).
Puts more burden on the API clients - e.g. PKI enrollment, management, etc. would need to be reliable, automated and abstracted.
So infeasible or too much friction for some APIs, but this would reduce the attack surface for a B2B API with a limited number of consumers...and many of those would take that tradeoff?
Of course, we still wouldn't 'trust' the private network overlay in our API definitions...it would just be one more layer of security if access is gated with modern cryptography.
of course gcp is the smallest of the three but not small as it approaches $20B.
do the #s track with what HN community has seen in comparing the three largest hyperscalers in function, pricing, reliability, etc?
reply