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?
Digging in a little bit more:
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').
Hope that helps. Any more questions, let us know!
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.
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:
- 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.