Ephemeral Services. MuleSoft Runtime meets zrok.io. OpenZiti has done it again.

For the past 04 months, I’ve been using the OpenZiti (https://docs.openziti.io/) technology. It has changed how I approach my customers in terms of security, zero trust concepts, API Security, and API strategies, among many other things. It has allowed me to mix different technologies and platforms such as MuleSoft, Oracle Cloud Infrastructure, and the OpenZiti/Netfoundry.io components.

OpenZiti has introduced the concept of Zero Trust Networking and has taken it to a next level. OpenZiti allows applications to communicate with each other in a highly secure fashion. For example:

1. OpenZiti JDBC drivers allow applications to connect to private Databases, from anywhere but securely. Without opening ports in the firewall, without using bastions, etc
2. OpenZiti SDKs allow applications to connect to dark APIs using pretty much any popular programming language. You can rest safely without having to open or expose your APIs to the internet, but at the same time have your public consumers reaching your resources through the internet
3. OpenZiti kubeZctl allows an operator to connect to private Kubernetes clusters from a different network (even public) without having to expose a single resource from your Kubernetes cluster, nor to have the need to create a Reverse Proxy, VPNs, or anything
4. OpenZiti BrowZer allows you to connect to private web applications, from external networks -even from the internet- without having to open a single port in your Firewall.
5. And the list can continue…

But guess what? Now they have created zrok.io (Home — zrok). They describe it like this:

The relevant word right here is sharing. Sharing resources with others. Sharing them ephemerally. Resources that may reside on your laptop but someone else, sitting on the internet or on a completely different network than yourself, needs to get access and you do not have a way to make it public. And at the same time, you do not want to take the risk to use a solution that will create a public endpoint, reachable from the internet that may put your resources at risk. Well, zrok.io will help you with that, whether you want to share the resource publicly or rest it privately.

Up to this point in time, I’ve identified that zrok.io has two elements to identify to work with it:

1. Zrok’s CLI (works both in windows and Linux)
2. Zrok.io web console

It is available as SaaS or self-hosted.

Zrok goes beyond just publishing HTTP/HTTPs resources. It can also share files and web content in general. Since this is my first approach, I will start with what I normally work with: REST services and APIs.

In the scenario I want to describe in this article, I have:

1. A MuleSoft Runtime running on my laptop
2. On top of that MuleSoft Runtime, I have a very simple resource that I have called /zrok. Which will respond with a simple GET
3. I have zrok on my laptop
4. I have a droplet in Digital Ocean from where I would like to get access to the /zrok resource
5. We will do it publicly and privately

This is the scenario for the pubic option:

(Taken from the zrok.io and modified to incorporate MuleSoft)

In this case, I have the /zrok resource being served locally (my laptop) but is accessed from the public internet (from a digital ocean droplet).

The resource is http://localost/zrok (just that simple).

In the second scenario, the private one, I have this:

(Taken from the zrok.io and modified to incorporate MuleSoft)

From the right side of the screen, is pretty much the same (the zrok command changes, we’ll take care of that in the following lines), the main difference -as you can imagine- is that the endpoint is not publicly available for others. It will be available just for those who also have zrok and that have access to a shared token, which we will get to that in a minute.

Let’s do it!

The first thing I encourage you to do is to download zrok, you can do it from here: Release v0.3.0-rc6 · openziti/zrok (github.com)

Once you have downloaded it, try this:

Secondly, zrok is so simple that all you need to understand are four commands:

1. zrok invite. This command will create an invitation for the user who will create the services/resources that need to be shared. I am not going to go into the details because that is very well documented here: https://docs.zrok.io/docs/getting-started. But in a nutshell, the zrok invite will prompt you for your email address, and once you type it you will receive a similar email to this one:

Scrolling down a little bit:

That will get you access to the zrok web console:

Click on the email address at the right top of the console, and it will show these options:

Click on Enable Your environment and it will show:

Copy the command and execute it

2. zrok enable. As explained previously the zrok enable <token> can be taken from the web console. And once you execute it, you can check the status of your account executing:

zrok status

That will show your config as well as your secret token and identity.

With this, you are ready to go to start sharing your resources ephemerally and securely.

Before showing how to share it, let’s just make a brief summary of what we have from the MuleSoft end.

First of all, I have hybrid deployment: the mulesoft runtime is on my laptop:

From Anypoint Platform:

In my Anypoint Studio, I have a very (extremely simple) application deployed with the name: zrokTest. The application is this one:

Listener is serving at port 80:

If I test it via a simple curl:

Now is the time to share that very simple resource. We will do it first publicly and then privately.

3. zrok share: Our first approach will be public:

zrok share public http://localhost

Once you execute that command, you will see this:

zrok has created the ephemeral service and is serving it at:

https://df81154kvl02.share.zrok.io

My very simple REST MuleSoft application can be accessed publicly using that endpoint.

Let’s try it from our Digital Ocean droplet:

Very simple. Just like that, I’ve exposed it publicly.

From the web console perspective you will see this:

Your account is enabled at certain places (my laptop in this case), and where I have it enabled there is a service pointing to that URL. Just that simple.

If I shoot down the exposed service, that is going to disappear from the console as well. Let’s do it, click on the X at the window:

The exposed service is gone, it is ephemeral.

Now let’s do the private approach:

zrok share private http://localhost

The command is pretty much the same, but it changes from public to private. Your service looks like this:

As you can see, in this case, the access point is not a URL, is a command:

zrok access private xmxfylvj0xlk

Which is the last command you need to understand.

4. zrok access: This command needs to get executed from the consumer end to get access to the service. Remember this image?

(Taken from the zrok.io and modified to incorporate MuleSoft)

That is exactly what we are doing.

From the consumer end, zrok needs to be installed and enabled. Let’s do it from our Digital Ocean droplet. Execute the previous command:

zrok access private xmxfylvj0xlk

As you can see it creates a local service in my droplet and gave access to it serving at port 9191. Now let’s execute from the Digital Ocean droplet a curl to that location:

In the zrok service console on my laptop, I’ve received a GET to /zrok:

Which ultimately is hitting my MuleSoft server.

Zrok.io is so simple to use and understand it. Give it a try, if you have scenarios where you need to share local resources with third parties or even for yourself, maybe for testing purposes, this is a very simple way to do it.