Not too long ago, I authored a post about why Go is Amazing for Zero Trust. In that post, I write about one of OpenZiti's superpowers that allows your applications to have no listening ports by integrating an OpenZiti SDK into it. It's always interesting writing content that makes perfect sense to you but after you publish it, someone immediately asks a question that's so obvious, you wonder how it is you, and everyone that reviewed it missed it. I published that blog post, and the first (well-deserved) response was:

We created OpenZiti so that anyone can implement distributed applications over the Internet, incorporating the principles of zero-trust networking for free into almost anything and for any use case.

We started the OpenZiti  GitHub org back in May 2020. One of the most common questions we get today is, "Why haven't you bumped the version to 1.0 yet?" It's a fair question. OpenZiti boasts a robust feature set and sees widespread use in mission-critical applications, including Fortune 50 environments, with billions of sessions annually.

So, why the long wait? Well, making secure connectivity simple at scale is non-trivial, and we’ve held ourselves to a high standard.

We’ve proved, and our users have proved, that OpenZiti stands up to large-scale production use. But one of the most important things we wanted to do before flipping to v1.0 was show off OpenZiti in action in its most potent use case: as a foundation for what we call “ziti-native apps.” These are applications built from the ground up with security, privacy, and resilience designed in.

PKCE, which stands for “Proof of Key Code Exchange”, and is pronounced “pixy,” is an extension of the OAuth 2.0 protocol that provides an additional security layer helping to prevent intercept attacks.

Articles about OpenZiti often discuss application and network security, and this article will follow that trend.

I love working remotely, and sometimes, ‘remote’ is truly out there. I’ve worked from faraway islands and foreign countries to your local coffee shop and campground. Regardless of where I’m at, I need one thing in particular: a secure connection to my workstation and development environment at home.

zrok is a powerful platform for sharing. The latest releases of zrok allow you to get granular about which other zrok accounts are allowed to privately access your shares.

zrok provides a number of powerful tools for sharing private resources. In addition to our multiple flavors of proxy support, web hosting, low level TCP and UDP sharing, and network drives support, zrok now includes the ability to hide or alter your IP address.

If you are reading this, hopefully, you are familiar with zrok: an open source solution for easy and secure sharing built on OpenZiti. If not you can check out this post introducing zrok. If you have then that's great news! You might be familiar with the Golang SDK that was recently released.

I like playing survival games, and my adult sons and I have been looking for a game we could play together. This weekend, we discovered Palworld, a new MMO available as an early release on Steam.

We recently had an issue where an OpenZiti network was overwhelmed with client requests when a user change unintentionally caused the request rate to spike. The fundamental problem was that if a request took too long, the client gave up, but the request was still processed. The system ended up doing work that was ignored while causing new requests to wait until they also timed out. Once the requests hit a certain threshold the system didn't degrade gracefully.

I had a fun day solving the problem, and while I'm sure that nothing here is new, I thought others might be interested in where I landed and some ideas that were rejected along the way.

With the release of v0.4.23, zrok now includes a set of CLI commands that simplifies the management of zrok virtual drives. This is an early preview of the full set of zrok Drives tools.