Howdy OpenZiti aficionados! I woke up this morning wanting to move a project forward but ran into a roadblock for which OpenZiti might be a great solution. I've been using OpenZiti self-hosted (a handfull of services, and a few Device Identities, all using ziti desktop edge) for about a year. No experience with SDKs or "zitified" software yet.
Scenario: A database-backed web application built on SvelteKit deployed to something like Netlify or Vercel. Relevant details: Vercel (Netlify is similar, will just use Vercel as the example from here on out) provides a fancy infrastructure for build and deployment of static AND dynamic web apps, "serverless" style, with "dynamic" stuff running on what they call "edge functions" which is a fancy way of saying "we manage setup/teardown of nodejs interpreters for your code to run on-demand, as needed, magically somewhere in The Cloud ".
Both the "build server" and the "edge functions" servers need access to the database at various points in time. If the database is not managed by Vercel, for instance say it is running on Digital Ocean or AWS RDS. then it is up to the application builder to secure that connection. Standard practice in securing Postgres database connections includes locking down IP addresses or ranges that should be allowed to connect. Vercel does not publish, and has publicly commented that it would be difficult to provide, IP addresses or ranges of their "build servers" or "edge function" servers.
So in this scenario one is left to either open up all IP addresses to the database server, or to find another solution. One solution I thought of was: make it so those "build servers" and "edge function" servers could talk over my existing OpenZiti infrastructure. This could either proxied, like an on-demand ziti-desktop-edge setup prior to opening the postgres connection, or maybe something else.
Is this a good idea? Any comments y'all might have about this approach, prior to diving in to see if I can make it work? I'm looking for any and all commentary, including good alternate non-ziti approaches. Is the startup time or client weight heavy, which might make running in these environments difficult? Anything I'm not thinking about?
it appears that the environments between Vercel's "edge functions" and "serverless functions" differ, with the former being more limited. In particular, "edge functions" can't use "native nodejs APIs", which I think means like their C api, and not "nodejs-only javascript APIs". Could be wrong on that. So consider this topic / question to be about "serverless functions" and not "edge functions", sorry for the incorrect terminology there previously.
y'all already do something like this in Java-land. But even with writing a ziti client in pure JS, which is a tall order for a non-expert anyway, it might not be possible to do a similar shim in Javascript-land. Which brings me back to the "fire up a local socket listener first and act like desktop edge tunnel" idea. Which again, even if both of those things were built I'd be surprised if that worked in an "edge functions" environment.
What you describe is a fantastic use-case for application embedded zero trust. If you do go the route of using a tunneler instead of an application embedded approach, the biggest benefit will be from familiarity. You'll be more familiar with deailing with that, probably. But, taking the time to go application embedded will make the node app portable to any nodejs runtime environment. You can run it locally to debug, you can send it to a friend to run (or collegue, client, etc). All you do is deploy your app and tell them how to configure the identity (or even automate that somehow). That's where the beauty of app embedded really shines through.
With application embedded, it'll just come down to "can you run code" (built into an executable, or interpreted like node/java/whatever) on that runtime. We do this very cleanly with Python and it's spelled out relatively well in this blog: Zero trust webhook from AWS Lambda You might also look at the GitHub actions we have which are definitely "serverless" OpenZiti ยท GitHub. We use these to notify our Mattermost server when something interesting happens on GiHub we want a message for...
You could also look at how I wrote the appetizer which runs in AWS fargate (containerized deployment, not exactly 'serverless').
Thanks! I'm going to stew on this a while. Success here depends on what the "edge functions" (which is deno, not nodejs, I believe, and is more restricted) and "serverless functions" environments actually support, which'll take some experimentation.
The only language-native SDKs y'all have are C, Java and Go, correct? The rest link against one of them (usually C I bet). And browzer doesn't seem to have an SDK per se, but it does have "core". Which uses WebSockets. I think if I went down that route I'd also have to have a Postgres driver which uses WebSockets. Someone's written a "pure" JavaScript postgres client, but it uses nodejs events so it'd have to be modified to use WebSockets. If WebSockets are even available in the aforementioned environments.
Do you have any commentary on the "startup time or client weight" question? Maybe that's subsumed by your initial reaction of it being a fantastic use case I don't have specific numbers, but I imagine in these kinds of environments they're very restrictive, and sensitive to, memory and total process run time, and they may or may not be very long lived.
The only language-native SDKs y'all have are C, Java and Go, correct?
I think that's correct. I feel like Browzer might have some subset of the sdk implemented but i'm not sure. I pointed curt here to comment if he has
Do you have any commentary on the "startup time or client weight" question?
Generally speaking, unless you're tearing down the whole thing and starting it all up again, you won't even notice it. It's probably like "50-100ms" or there abouts? This is just a total guess but I'd say it's long enough for your process to:
start
read a file or env var
use the file/env var to auth to openziti (which requires a new tcp connection, so tls negotiation, authentication, etc) -- probably 20-40ms ish depending on how far from the controller and the internet weather etc...
connect to one or more routers (20-40ms ish)
Once started, you'll never notice any overhead imo. I routinely ssh through ziti and it just 'feels like normal internet' to me.
That's correct. We do not (currently) offer an SDK that facilitates doing manual instrumentation of your web app's JS code and allowing it to access Services on a Ziti network (separate from browZer).
That said, we do anticipate the creation of what will probably be called the ziti-sdk-browser to make the above a reality, and that SDK will be constructed from selected existing components now used by browZer.
".
I don't have specific numbers, but I imagine in these kinds of environments they're very restrictive, and sensitive to, memory and total process run time, and they may or may not be very long lived.