How Can I View Active Ziti Sessions?

Support General Questions
1

Hello, friends!

For ziti 2.0.1, I’m having trouble viewing active sessions. Both the Ziti CLI and ZAC return an empty session list, even though ZDEW and ZET appear to be logged in, as indicated by the green status dots for their identities in ZAC.

I see similar behavior when listing API sessions: an API session appears only after I run ziti edge login.

Is this expected, or is there another command or view I should use to see these active sessions?

2

With 2.0+, the default is OIDC sessions, which are just JWTs and aren't backed by the database anymore. There are two paths open to you, depending on what your goals are:

  1. OIDC sessions do still generate API session events. So you can ingest those into the time series DB of your choice and slice and dice the data to give you the views/reports you need
  2. If you want to see who's actually connected, you can look at identities. They have a 'edgeRouterConnectionStatus' field, so you can see who is connected to edge routers.

For more granular access level, there are the circuit and usage events that tell which identities are using which services and how much data is flowing, attributable to services, routers and identities.

Hope that's helpful,
Paul

3

Are there any plans to restore the session list? It seems like a commonly expected feature that would be useful to many users.

4

I've thought about it a bit, so here are my my thoughts:

For background, moving to OIDC/JWTs gave us three benefits:

  1. Authorization that didn't require sessions to be coordinated across controllers.
  2. Authorization that didn't require sessions to be coordinated across routers.
  3. Removing the write load of sessions from controllers.

The straightforward path for making api sessions queryable would be to put them back in the database and would undo the benefits of 1 and 3. Legacy apii sessions and edge sessions are the biggest write load for controllers and have proven to be scalability bottlenecks for larger networks.

There are two paths I considered for bringing the functionality back natively (as opposed to the external time-series db approach):

  1. As mentioned, we can generate api session event to disk. If that's enabled, we could parse those files and load everything that's not expired into memory and run the query against an in-memory snapshot. It would require a specific configuration. You'd want to separate api session events from other events to minimize disk i/o. It would not be very efficient. But if you only want it for occasional ease of accessing auditing data, it would maybe work. Here's where my developer brain says, if we do it for api session, why not do it for all the event types? And then it immediately says, you're building an ugly time series db with terrible performance, just use influx or elastic. Also, it doesn't solve the HA problem, so you'd have to run it against all controllers, or have the query spider out to all the controllers, which would be even worse for performance.

  2. We're building out a gossip framework for links, terminators and router presence. We could re-use that for api sessions and do in-memory scan against gossip propagated api sessions.

I think the question that needs to be answered is, what do you use the api session list for?

  1. Auditing: That's what the events are there for. They provide a historical view of the data, where the session list was only for current.
  2. To see if a client is working: For this, the identity.edgeRouterConnectionStatus is very helpful, but not complete. You may have an sdk which is creating api sessions but not connecting to any database. You may have an admin who is just doing admin operations and will never connect to any ERs. I will note that you can stream events, including api sessions, so you could ask a user to reconnect and see if they create an api session, but the stream is per-controller, so still a bit annoying.
  3. As a proxy for how busy the system is?
  4. Other?

If you want to share your thoughts on why the list is important/how you use it, that would be helpful. Depending on the answer, that might lead us in different directions.

Paul

5

Because OpenZiti ultimately controls access to protected services, operators need visibility into the current sessions, authentication state, and authorization state. Historical events are useful for audit and investigation, but relying on them to reconstruct current access state places the burden on operators to deploy and maintain a separate system for a capability that an access control product should reasonably provide.