v1.0.7

CHANGELOG

FEATURE: zrok Agent now supports health checks (against the target endpoint) for proxy backend shares using the zrok agent share http-healthcheck command. The zrok API now includes an /agent/share/http-healthcheck endpoint for remotely performing these checks against remoted Agents. See the guide for using the feature at https://docs.zrok.io/docs/guides/agent/http-healthcheck/ (#1002)

FEATURE: /overview, /detail/share, /detail/environment, and /overview/{organizationToken}/{accountEmail} all adjusted to include envZId in share detail output (#998)

FEATURE: New add and delete API endpoints for frontend grants. New zrok admin create frontend-grant and zrok admin delete frontend-grant CLI for invoking these API endpoints from the command line (#992)

FEATURE: New admin endpoint for deleting accounts. New zrok admin delete account CLI for invoking the API endpoint from the command line (#993)

FEATURE: New admin endpoint for deleting identities. New zrok admin delete identity CLI for invoking the API endpoint from the command line (#800)

FEATURE: New API endpoint (/overview/public-frontends) that returns the public frontends available to authenticated account. The public frontends include those marked with the open permission mode, and those marked closed where the user has a frontend grant allowing them to access the frontend. New CLI command zrok overview public-frontends to allow end users to list the public frontends their account can use (#996)

CHANGE: Updated openapi-generator-cli from 7.12.0 to 7.14.0

v1.0.6

CHANGELOG

CHANGE: The /overview endpoint has been adjusted to include a new remoteAgent boolean on the environment instances, indicating whether or not the environment has an enrolled remote agent (#977)

CHANGE: Adjusted core framework entry points to support changing zrokdir, and host interrogation functions to better support embedded zrok functionality (#976)

v1.0.5

CHANGELOG

FEATURE: Initial support for zrok Agent remoting; new zrok agent enroll and zrok agent unenroll commands that establish opt-in remote Agent management facilities on a per-environment basis. The central API has been augmented to allow for remote control (creating shares and private access instances) of these agents; see the remoting guide for details (#967)

CHANGE: zrok share public, zrok share private, and zrok reserve all default to the "closed" permission mode (they previously defaulted to the "open" permission mode). The --closed flag has been replaced with a new --open flag. See the Permission Modes docs for details (#971)

FIX: zrok enable now handles the case where the user ID does not resolve to a username when generating the default environment description (#959)

FIX: Linux packages were optimized to avoid manage file revision conflicts (#817)

v1.0.4

CHANGELOG

FIX: zrok admin bootstrap and zrok enable functionality were broken in v1.0.3. A bad combination of dependencies caused issues with marshalling data from the associated controller endpoints

CHANGE: github.com/openziti/sdk-golang has been updated to v1.1.0, github.com/openziti/ziti has been updated to v1.6.0. Related dependencies and indirects also updated

CHANGE: Updated to golang v1.24 as the official build toolchain

v1.0.3

CHANGELOG

FEATURE: zrok agent console now outputs the URL it is attempting to open. New zrok agent console --headless option to only emit the agent console URL (#944)

FEATURE: New zrok admin unbootstrap to remove zrok resources from the underlying OpenZiti instance (#935)

FEATURE: New InfluxDB metrics capture infrastructure for zrok test canary framework (#948)

FEATURE: New zrok test canary enabler to validate enable/disable operations and gather performance metrics around how those paths are operating (#771)

FEATURE: New zrok test canary infrastructure capable of supporting more complex testing scenarios; now capable of streaming canary metrics into an InfluxDB repository; new programming framework for developing additional types of streaming canary metrics (#948 #954)

FEATURE: All zrok test canary commands that have "min" and "max" values (--min-pacing and --max-pacing for example) now include a singular version of that flag for setting both "min" and "max" to the same value (--pacing for example). The singular version of the flag always overrides any --min-* or --max-* values that might be set

CHANGE: New guard to prevent users from running potentially dangerous zrok test canary commands inadvertently without understanding what they do (#947)

CHANGE: Updated npm dependencies for ui, agent/agentUi and website. Updated github.com/openziti/sdk-golang to v0.24.0

v1.0.2

CHANGELOG

FEATURE: "Auto-rebase" for enabled environments where the apiEndpoint is set to https://api.zrok.io. This will automatically migrate existing environments to the new apiEndpoint for the v1.0.x series (#936)

FEATURE: New admin/new_account_link configuration option to allow the insertion of "how do I register for an account?" links into the login form (#552)

CHANGE: The release environment, share, and access modals in the API console now have a better message letting the user know they will still need to clean up their zrok processes (#910)

CHANGE: The openziti/zrok Docker image has been updated to use the latest version of the ziti CLI, 1.4.3 (#917)

v1.0.1

CHANGELOG

FEATURE: The zrok Agent now persists private accesses and reserved shares between executions. Any zrok access private instances or zrok share reserved instances created using the agent are now persisted to a registry stored in ${HOME}/.zrok. When restarting the agent these accesses and reserved shares are re-created from the data in this registry (#922)

FEATURE: zrok-agent Linux package runs the agent as a user service (#883)

CHANGE: Updated the "Getting Started" guide to be slightly more streamlined and reflect the v1.0 changes (#877)

CHANGE: let the Docker instance set the Caddy HTTPS port (#920)

CHANGE: Add Traefik option for TLS termination in the Docker instance (#808)

v1.0.0

Quick Tip: If you upgrade your client to v1.0.0 and you receive an error message like this:

[ERROR]: unable to create share (error getting zrok client: client version error accessing api endpoint 'https://api.zrok.io': [POST /clientVersionCheck] clientVersionCheck (status 404): {}: [POST /clientVersionCheck] clientVersionCheck (status 404): {})

A simple zrok rebase apiEndpoint https://api-v1.zrok.io will get you up and running on the new version.

CHANGELOG

MAJOR RELEASE: zrok reaches version 1.0.0!

FEATURE: Completely redesigned web interface ("API Console"). New implementation provides a dual-mode interface supporting an improved visual network navigator and also a "tabular" view, which provides a more traditional "data" view. New stack built using vite, React, and TypeScript (#724)

FEATURE: New "zrok Agent", a background manager process for your zrok environments, which allows you to easily manage and work with multiple zrok share and zrok access processes. New --subordinate flag added to zrok share [public|private|reserved] and zrok access private to operate in a mode that allows an Agent to manage shares and accesses (#463)

FEATURE: New "zrok Agent UI" a web-based user interface for the zrok Agent, which allows creating and releasing shares and accesses through a web browser. This is just an initial chunk of the new Agent UI, and is considered a "minimum viable" version of this interface (#221)

FEATURE: zrok share [public|private|reserved] and zrok access private now auto-detect if the zrok Agent is running in an environment and will automatically service share and access requests through the Agent, rather than in-process if the Agent is running. If the Agent is not running, operation remains as it was in v0.4.x and the share or access is handled in-process. New --force-agent and --force-local flags exist to skip Agent detection and manually select an operating mode (#751)

FEATURE: zrok access private supports a new --auto mode, which can automatically find an available open address/port to bind the frontend listener on. Also includes --auto-address, --auto-start-port, and --auto-end-port features with sensible defaults. Supported by both the agent and local operating modes (#780)

FEATURE: zrok rebase commands (zrok rebase apiEndpoint and zrok rebase accountToken) allows "rebasing" an enabled environment onto a different API endpoint or a different account token. This is useful for migrating already-enabled environments between endpoints supporting different zrok versions, and is also useful when regenerating an account token (#869, #897)

FEATURE: zrok test canary CLI tree replaces the old zrok test loop tree; new zrok test canary public-proxy and zrok test canary private-proxy provide modernized, updated versions of what the zrok test loop commands used to do. This new approach will serve as the foundation for all future zrok testing infrastructure (#771)

FEATURE: New /api/v1/versions endpoint to return comprehensive, full stack version information about the deployed service instance. Currently only returns a single controllerVersion property (#881)

CHANGE: The default API URL for v1.0.x zrok clients is now https://api-v1.zrok.io (instead of the older https://api.zrok.io). The zrok.io deployment will now be maintaining version-specific DNS for versioned API endpoints.

CHANGE: Refactored API implementation. Cleanup, lint removal, additional data elements added, unused data removed (#834)

CHANGE: Deprecated the passwords configuration stanza. The zrok controller and API console now use a hard-coded set of (what we believe to be) reasonable assumptions about password quality (#834)

CHANGE: The protocol for determining valid client versions has been changed. Previously a zrok client would do a GET against the /api/v1/version endpoint and do a local version string comparison (as a normal precondition to any API call) to see if the controller version matched. The protocol has been amended so that any out-of-date client using the old protocol will receive a version string indicating that they need to uprade their client. New clients will do a POST against the /api/v1/clientVersionCheck endpoint, posting their client version, and the server will check for compatibility. Does not change the security posture in any significant way, but gives more flexibility on the server side for managing client compatibility. Provides a better, cleared out-of-date error message for old clients when accessing v1.0.0+ (#859)

CHANGE: The Node.js SDK is now generated by openapi-generator using the typescript-fetch template. Examples and SDK components updated to use the v1.0.0 API and generated client (#893)

CHANGE: The Python SDK is now generated by openapi-generator and requires a newer urllib3 version 2.1.0. The published Python module, zrok, inherits the dependencies of the generated packages (#894)

v0.4.49

CHANGELOG

FIX: Release artifacts now include a reproducible source archive. The archive's download URL is now used by the Homebrew formula when building from source instead of the archive generated on-demand by GitHub (#858).

FIX: Pre-releases are no longer uploaded to the stable Linux package repo, and workflows that promote stable release artifacts to downstream distribution channels enforce semver stable release tags, i.e., not having a semver hyphenated prerelease suffix.

CHANGE: The release checksums.txt has been renamed checksums.sha256.txt to reflect the use of a collision-resistant algorithm instead of shasum's default algorithm, SHA-1.

CHANGE: The dependency graph is now published as a release artifact named sbom-{version}.spdx.json (#888).

CHANGE: Pre-releases are uploaded to the pre-release Linux package repo and Docker Hub for testing. RELEASING.md describes releaser steps and the events they trigger.

CHANGE: Linux release binaries are now built on the ziti-builder container image based on Ubuntu Focal 20.04 to preserve backward compatibility as the ubuntu-20.04 GitHub runner is end of life.

CHANGE: Container images now include SLSA and SBOM attestations, and these are also published to the Docker Hub registry (#890).

CHANGE: Release binary and text artifacts are now accompanied by provenance attestations (#889).

v0.4.48

CHANGELOG

FEATURE: The controller configuration now supports a disable_auto_migration boolean in the store stanza. When set to true, the controller will not attempt to auto-migrate (or otherwise validate the migration state) of the underlying database. Leaving disable_auto_migration out, or setting it to false will retain the default behavior of auto-migrating when starting the zrok controller. The zrok admin migrate command will still perform a migration regardless of how this setting is configured in the controller configuration (#866)

FIX: the Python SDK erroneously assumed the enabled zrok environment contained a config.json file, and was changed to only load it if the file was present (#853)