ObserveKit Help
Back to app

Roles & permissions

Access in ObserveKit is role + source scope. There are three roles and a per-user list of sources ("scopes"). There is no separate per-feature permission grid — these two things determine everything.

The three roles

RoleSeesCan do
AdminAll sources (bypasses scopes)Everything: create/delete sources, manage all users, rotate API keys, regenerate install links, add/remove any member
ManagerOnly sources in their scopeView those sources; add/remove viewer members on them (see below). Cannot grant admin/manager, cannot manage other managers
ViewerOnly sources in their scopeRead-only. Cannot manage members or sources

Source scope — who sees which source

For non-admins, visibility is governed by the user's scopes: a list of source IDs.

  • A non-admin sees only the sources in their scopes. Empty scopes → they see nothing. (Admins ignore scopes and see all.)
  • Requesting a source outside your scope returns 404, not 403 — ObserveKit doesn't reveal that a source you can't access exists.

Two ways to grant access — same underlying list

You can edit a user's source access from either direction; both write to the same scopes list:

  • Users page → set a user's assigned sources directly.
  • Source detail → Members → "add member" appends that source to the user's scopes.

So "members of a source" and "a user's scopes" are two views of one thing. Granting via Members is just a per-source shortcut for editing scopes.

Member management rules (who can grant what)

  • Admin — add/remove any user on any source, at any role.
  • Manager — on sources in their own scope, can add or remove viewer-role users only. Cannot add or grant admin/manager, cannot remove another manager, and cannot remove themselves.
  • Viewer — cannot manage members (403).
  • No user can edit their own scopes via the API.

SSO / OIDC role mapping

With OIDC (e.g. Azure AD), map an identity-provider group to an ObserveKit role via auth.oidc.role_mapping in the server config (group ID → admin / manager / viewer). Users signing in through SSO get the mapped role; scopes are then managed as above.

Rule of thumb

  • Give operators manager scoped to the clusters/services they own.
  • Give read-only stakeholders viewer scoped to what they need to see.
  • Keep admin to the few who manage the platform itself.
PreviousManaging users