Moving applications that have baked-in identity enables zero trust networking that is more secure for your development environment. The OpenZiti Project provides an open source platform that enables such zero trust networking over the Internet.

I recently video streamed a conversation with Ken Bingham and Clint Dovholuk from NetFoundry, which is the originator and leading contributor to the OpenZiti Project. They showed me how to use Ziti and Kubernetes to create an overlay network that connects AWS and IBM Cloud with just our laptops in less than an hour. Video clips of our chats are interspersed throughout this article.

What is Ziti

Ziti is an application delivery platform and a programmable overlay that provides secure connectivity on top of an existing networking infrastructure. If you couple your application with the Ziti identity, then the application can connect with any programs that your overly allows. Ziti is about taking zero trust to the next level by adding strong identity directly into your application.

Ziti provides a secure connection all the way to your server. So, you can use one of its SDKs, which are available in many different programming languages, and bake it into both your client application and your server application. You then have an encrypted tunnel that goes from the process space in your application all the way to the process space inside of your server with the help of desktop or mobile edge "tunneler" agents that you install. When you embed a tunneler into your application, there is not a VPN since it's literally baked into the application itself. This makes a lot of ransomware-type attacks useless against something with this kind of protection.

If you are interested in building something such as a mobile client with a server stack, you don't want that server to be unnecessarily exposed to the Internet. You can just put it behind the Ziti Fabric mesh so it won't be attacked from anywhere except the particular Ziti identities that you authorized for it. When you communicate on the Ziti network, you not only verify the certificate that the network presents, but the network also verifies your certificate. So, before you even access the network, you're already authenticated, and then you are authorized by the Ziti Controller.

NetFoundry conducted many tests with Ziti that show that its network performs faster than the open Internet. As Clint and Ken talked about during our streaming session, it's amazing how it can be faster to take two hops someplace than it is to go straight there. It is the smart routing that's the adaptive piece of the permissionless mesh. It provides on ramps and off ramps with the edge piece. You can configure how you get on and off the Ziti superhighway, going around what they called "Internet weather" (noise or issues).

Using Ziti with Kubernetes

Before we started to build, Ken explained the two Kubernetes clusters that we would create to demonstrate the power of Ziti. As the following diagram illustrates, I host a web app in my Kubernetes cluster that can reach out to whatever is installed there and serve it up to the Ziti network. (Note that I used a new cluster hosted on the IBM Cloud.) The Ziti components inside of my cluster help the app go out through my net or public IP to the Ziti Fabric.

Diagram of the Kubernetes clusters within the Ziti network

Install the Helm chart

I started the process of installing Ziti to my Kubernetes cluster by downloading a Helm chart that the NetFoundry team created. To do this yourself, follow the NetFoundry Helm Charts repository instructions.

Create an endpoint enrollment token

A JSON web token (JWT) is a necessary part of the Ziti enrollment process because it's how you generate the strong identity for your application. Ken set up the Ziti network enrollment token (a .jwt file) for me in advance to speed up our live stream session, but you can follow the steps within the Install Ziti in Kubernetes guide to create your own network and endpoint identify file.

The JWT is created from the control plane. So, if we were using some type of configuration management, such as Ansible or Chef, we would have to create each of these and then put it into the system.

Provision identities and define a service

While I loaded the appropriate Ziti tunneler agent on my laptop, Ken opened the NetFoundry console so we could see what's going on in the back end. My laptop quickly appeared as a registered endpoint (identity).

The primary function of Ziti is to securely connect "services" across a network, whether an application or other type of resource. But instead of a DNS name or IP address, a Ziti Service is defined by a custom name or certificate.

Ken used the NetFoundry console to define the service that's on my Kubernetes cluster, It's possible to provision Ziti identities and define a service without the NetFoundry version of Ziti in the following ways:

A command line interface with access straight into the Ziti Controller.
The Ziti Administration Console (ZAC), which is truly a bare bones environment.

Expose the cluster service

The awesomeness of Ziti was fully apparent when we exposed my Kubernetes cluster service to the Ziti network. The Hello World app running in my cluster was now visible from my laptop browser through the custom domain name that we defined for the service.

We essentially created a narrow, specific app network and delivered the app to only the devices that we authorized. With Ziti, it doesn't matter where an app is running because it's all on its own overlay network with its own domain.

Ziti and multicloud clusters

Next, we demonstrated the multicloud capabilities of Ziti by spinning up another application within Ken's AWS cluster to talk with the IBM Cloud cluster running on my laptop.

As Ken wired our clusters together and created the new Ziti Service, the option of using a sidecar pattern came up. So, next we whipped up a Kubernetes deployment within in my IBM Cloud cluster to run a curl command in a loop. (You can try this yourself to by following the Kubernetes Sidecar docs.)

The Ziti tunnel sidecar accesses its identity by mounting a Kubernetes secret in the container. Therefore, I needed a new JWT file to mount as the secret. As a reminder, JWT files are important for the Ziti network because they provide specific permissions and are crucial for securing identity on your machine.

We configured a proxy to bind the Ziti Service on Ken's cluster. During some small delays and troubleshooting (unfortunately, the JWT was burned, so we had to create another one), we talked about some of the available permission, configuration, and role attributes to form policies for endpoints to go on and off the Ziti Fabric mesh network.

Building a multicloud, zero trust network with Ziti and Kubernetes

Building a multicloud, zero trust network with Ziti and Kubernetes