Compatibility of Zrok share 1.1.5 with OpenZiti

zrok
1

Could you please clarify what I should check in order to install and run Zrok 1.1.5 successfully?

My current setup is as follows:

  • Ziti Controller: 1.6.7

  • Ziti Routers: 1.6.10 ( with a deadlock fix )

  • Zrok Controller: 1.1.2

With this configuration, Zrok 1.1.2 works quite well.

However, after upgrading to Zrok 1.1.5, I encounter the following issues:

  • The Ziti Controller does not display the api-session.

  • zrok share/agentremoting does not work — the controller does not show terminators.

  • On the other hand, zrok access still functions correctly.

  • Running ziti fabric list circuits shows the tags.clientId.

Could you please advise what I should verify or adjust to resolve this compatibility issue?

Should the version of the zrok controller match the version of the zrok share client, or is it acceptable to run different versions?

2

There is nothing materially different that would affect the ziti interoperability between 1.1.3 and the current revisions higher than 1.1.3.

We keep a detailed change log:

1.1.3 is where the underlying ziti SDK was updated. Are you able to use 1.1.3?

3

And generally you should try to run the same zrok client versions as the zrok controller. They’re usually generally compatible if they’re in the same minor version, but there may be small feature-specific differences.

Mismatched zrok client/controller would not cause any of the issues you’re seeing.

4

I have installed Zrok 1.1.7 (both controllers and client), Ziti 1.6.10

  • The zrok access 1.1.7 command works as expected.

  • However, when I run: ziti edge list api-sessions 'limit none'

    the output only shows the Default Admin session.

There are no other identities listed — not even the public identity.
Despite this, the web frontend itself does work.

It seems that the controller is not displaying any identities beyond Default Admin.

When running Zrok 1.1.2, I get the expected identities from the ziti-controller:

ziti edge list api-sessions 'limit none' -j | jq -c '.data[] | [.identityId, .ipAddress]'
["user_zID","XXX.XXX.XXX.XXX"]
["user_zID","XXX.XXX.XXX.XXX"]

But using zrok 1.1.7 I got wrong zID for the same IP address

ziti edge list api-sessions 'limit none' -j | jq -c '.data[] | [.identityId, .ipAddress]'
["DefaultAdmin_zID","XXX.XXX.XXX.XXX"]

It appears that in Zrok 1.1.7, the zrok-controller’s own identity ID is being used in place of the actual env. identity.

5

Starting from Zrok 1.1.3, the ziti-controller appears to show an incorrect identity and IP address for active api-sessions (while using ziti 1.6.10).

As a result, I can no longer see the actual identity in the output of:

ziti edge list api-sessions 'limit none' -j | jq -c '.data | [.identityId, .ipAddress]'

It seems that the identities are being associated with the controller’s own ID, possibly causing them to be mangled or overwritten.

With Zrok 1.1.2, the identities and IPs are displayed correctly.

Starting from Zrok 1.1.3, the output only shows DefaultAdmin_zID.

At the moment, it is unclear which Ziti version is fully compatible with Zrok 1.1.3 and later releases.

6

We regularly run both ziti 1.5.x (typically 1.5.4) and ziti 1.6.x (typically 1.6.7) with a multiplicity of zrok versions, in a number of high-volume and production environments, and we don’t run into these kinds of problems. So, it makes it a little challenging to try and offer help. It’s hard to reproduce what you’re reporting.

Maybe share your ziti controller configuration so we can take a look at it?

7

zrok 1.1.3 uses OIDC tokens by default, which means we don't create legacy api session entries.

If you want visibility into sessions, you can enable api session events, and both legacy and OIDC sessions will generate events.

One of the goals of OIDC sessions was to not require creating a database entry per session, and to remove the need to propagate sessions to all the routers. The visibility is still there, via the events, but since those are events, not queryable state, it puts some of the burden on the administrator.

However, you can still see who is connected to an edge router, using the edgeRouterConnectionStatus field on identity. That combined with the event log should let you see who is able to connect, and if diagnose connection issues.

Let me know if that's helpful,
Paul