4.6 KiB
Public/Private Sharing
The v0.3
series introduces new sharing modes, and new types of built-in services.
Share Modes
Note: In v0.3
, the tunnel
and untunnel
concepts get renamed to share
and unshare
.
Note: We're going to continue using frontend
and backend
as concepts, even though those words will be changing in the zrok
CLI. A frontend
will continue to describe an "ingress" into the zrok
service, and is the tool that is used by the user "consuming" or access
-ing the the zrok
service. A backend
will continue to describe the "binding" created by a user that wants to share
a resource.
Public Sharing
In v0.2
, zrok
only offered a "public" sharing mode. The public sharing mode will allow any configured frontend
instances to send traffic to any backend
. The policy and permission model was very simple and flat. A v0.2
deployment considers any available frontend
instance to be allowed to send traffic to configured services. The access for frontend
instances is controlled by identity provisioning within the underlying Ziti network.
In v0.3
, zrok
will offer both a "public" and a "private" sharing mode. When v0.3
configures the policies for a service, a publicly-shared service will have policies created that allow whichever selected public frontend
instances to access the shared backend
. A v0.3
deployment will have a collection of multi-tenant, high-capacity frontend
instances available to be selected from. The zrok
CLI will default to selecting the public
frontend
instances.
The frontend
selection approach also gives us a clean implementation for picking public frontend
instances based on geography (either network or physical). The production zrok.io
service could easily offer multiple different fleets of frontend
instances, and this mechanism will allow backend
users to choose where they want to offer access to their service.
Private Sharing
v0.3
introduces a "private" sharing mode. When provisioning a service for private sharing, zrok
will not create any policies for the service, until a request for a frontend
binding is created for the service (through the v0.3
zrok access
command).
The v0.3
zrok
API will support creating frontend
instances for both identified users (where the zrok
user has a provisioned environment
), as well as ephemeral users (the zrok
controller will create a single-use "ephemeral environment" for these frontend
instances).
Backend Modes
In v0.2
, the only possible backend
"mode" was used for reverse proxying HTTP traffic to a local endpoint. The v0.3
zrok
client will support several different backend
modes, providing a number of built-in conveniences.
Web Mode
A user has a collection of files on disk. Sharing with a backend
mode of "web", will create a backend
that shares a file tree as if it were a local web server. This effectively allows a user to bind a web-server backend to a document root with a single CLI command.
DAV Mode
A user wants to operate a read/write repository of files accessible through either conventional WebDAV clients (through public
frontend
instances), or through the zrok
CLI (a convenience wrapper, embedding WebDAV capabilities).
This allows users to create read/write repositories of files that can be shared with multiple users, and also allows for the creation of write-only "drop boxes" for receiving files from another user (often a tricky thing to do well and securely on the public internet).
Proxy Mode
v0.3
will retain the classic reverse proxy mode, as well. Will continue to allow a user to expose a local HTTP endpoint through zrok
.
Entities (SQL)
v0.3
introduces a new frontends
table to allow the zrok
controller to track the frontend instances that are available to any account or environment.
The following illustration shows the possibilities available.
The *.in.zrok.io
frontend is a "public" frontend, available to all zrok
users. Most zrok
installations will want to have at least one public, global frontend for all public, internet-facing ingress traffic for private backend instances. In the underlying data store, the public frontend will have a name
set to public
(or some other representative name), allowing users to reference that frontend
using a friendly label.
The other two "private" frontends are configured with no name
label (the lack of a name
label signifies that these are "private" frontends). The ephemeral environment is allocated when a zrok
frontend request is made without an account on behalf of a private share.