Feature Request: Layer-Scoped RBAC for Multi-Tenant Deployments (Horizon UI)

[aliebrahimy]

Hi Horizon UI team,

First, thank you for the excellent work on Horizon UI. We are deploying it in a multi-tenant environment with multiple Kubernetes clusters and Docker-based services, and we use OAP service groups (via the group::service naming convention) to logically separate services by team (e.g., payments::, risk::).

Current Limitation:

As documented, Horizon's RBAC operates at the verb level (e.g., metrics:read, traces:read) and does not support resource-level restrictions. A user with the viewer role can see all Layers in the sidebar and access metrics for all services, regardless of which group they belong to.

While splitByServiceGroup in layer templates provides a UI grouping, it is a presentation feature and does not enforce any access control. A curious user can simply switch the group dropdown and see other teams' services.

Use Case:

We want to assign users to a role that only grants access to a specific Layer (or a set of Layers). For example:

A user with payments-viewer role should only see the PAYMENTS layer in the sidebar and access its metrics/traces/logs.

The same user should be unable to query metrics for the RISK layer, even if they know the correct MQE expression or URL.

Proposed Feature:

We would like to request Layer-Scoped RBAC where grants can be narrowed to specific Layers. Some possible syntax options:

metrics:read:PAYMENTS (grant read access only to the PAYMENTS layer)

traces:read:PAYMENTS,RISK (multiple layers)

Or a separate allowedLayers array per role in horizon.yaml:

rbac: roles: payments-viewer: - metrics:read - traces:read - logs:read allowedLayers: ["PAYMENTS"]

mpact:

This would enable secure multi-tenant deployments where teams only see their own observability data, aligning Horizon UI with enterprise access control requirements.

Thank you for considering this feature. We are happy to provide more details or test any prototype.

[wu-sheng]

Layer-scoped RBAC is not there, that is true.

But I am wondering about this statement from you: While splitByServiceGroup in layer templates provides a UI grouping, it is a presentation feature and does not enforce any access control. A curious user can simply switch the group dropdown and see other teams' services.. With the latest splitByServiceGroup option in layer time, it locks the menu entrance by different groups.

RBAC is no longer layer-scoped only, it is actually a menu-level thing.

[wu-sheng]

I used the following RBAC config to test how this works

rbac:
  builtinRoles: keep        # viewer, maintainer, operator, admin stay as shipped
  roles:
    payments-team:
      - "metrics:read@GENERAL[payments]"
      - "traces:read@GENERAL[payments]"
      - "logs:read@GENERAL[payments]"
      - "topology:read@GENERAL[payments]"
      - "alarms:read@GENERAL[payments]"
      - "profile:read@GENERAL[payments]"
      - overview:read
    risk-team:
      - "metrics:read@GENERAL[risk]"
      - "traces:read@GENERAL[risk]"
      - "logs:read@GENERAL[risk]"
      - "topology:read@GENERAL[risk]"
      - "alarms:read@GENERAL[risk]"
      - overview:read
    general-team:
      - "metrics:read@GENERAL"
      - "traces:read@GENERAL"
      - "logs:read@GENERAL"
      - "topology:read@GENERAL"
      - "alarms:read@GENERAL"
      - overview:read
    so11y-watcher:
      - "metrics:read@SO11Y_OAP"
      - "topology:read@SO11Y_OAP"
    mixed-team:
      - "metrics:read@GENERAL[payments]"
      - "logs:read@GENERAL[risk]"
      - alarms:read           # plain: alarms on every layer
      - overview:read

auth:
  backend: local
  local:
    users:                  # password == username; argon2 hashes are in rbac-demo/users.json
      - { username: viewer,     passwordHash: "…", roles: [viewer] }
      - { username: maintainer, passwordHash: "…", roles: [maintainer] }
      - { username: operator,   passwordHash: "…", roles: [operator] }
      - { username: admin,      passwordHash: "…", roles: [admin] }
      - { username: payments,   passwordHash: "…", roles: [payments-team] }
      - { username: risk,       passwordHash: "…", roles: [risk-team] }
      - { username: general,    passwordHash: "…", roles: [general-team] }
      - { username: so11y,      passwordHash: "…", roles: [so11y-watcher] }
      - { username: mixed,      passwordHash: "…", roles: [mixed-team] }

user=built-in viewer(Sees both GENERAL group entries and Virtual Database; no Platform monitoring section)

user=payments granted as read@GENERAL[payments] (Only payments · General Service (payments::checkout, payments::ledger))

user=general use granted as read@GENERAL

[wu-sheng]

Two additions for alarms are in apache/skywalking-horizon-ui#179, also planned for Horizon 1.1.0.

Alarms follow the grant

In #178, a role limited with alarms:read@GENERAL[payments] had to pick a service before the Alarms page showed anything, and the alarm count was not available, as I noted above. With #179, the alarm list, the alarm count in the sidebar and top bar, the overview Alarms widget and the 3D map all show the alarms of the services the grant covers. That means the alarms on those services, on their instances and endpoints, and on relations where either end is one of them. No service needs to be picked first.

Alarm pages per team

Besides the Alarms page, you can now add named alarm pages at Dashboard setup → Alarm pages, for example one per team. Each page pins layers, optionally narrowed to service groups, written the same way as a grant:

GENERAL              # every GENERAL service
GENERAL[payments]    # the payments services in GENERAL

• Each page is its own sidebar entry after Alarms, at /alarms/<id>.
• A page lists only the alarms its pins cover, and its filters offer only its own layers and services.
• A role sees a page when its alarms:read reaches at least one of the page's pins.
• A page never widens what a role reads: the grant still decides which alarms exist. So general-team (alarms:read@GENERAL) opening Payments on-call sees the payments alarms only, and payments-team is not shown Risk on-call at all.
• A team can land on its page with landingByRole:

rbac:
  landingByRole:
    payments-viewer: /alarms/payments

One upgrade note: the Alarms page's own setup is now stored as horizon.alert.default instead of horizon.alert.page-setup. If you changed its pinned layers, window or overview alarm limit, set them again after upgrading.

Docs are in Customization → Alarm Pages and Access Control → Roles and Permissions. They'll be published after the PR is merged, and you can read them in the PR now. Feedback on the PR is welcome, especially from your LDAP and service-group setup.

[aliebrahimy]

Thanks for the implementation and for the detailed explanation.

I built and tested the new Horizon UI branch with our LDAP and service-group setup. So far, I’ve checked the access-control behavior, roles, grants, and service-group visibility, and everything looks good. I haven’t encountered any issues with the LDAP/RBAC part.

I did notice one issue in the Topology view, though.

When I click on an object and select Open Service, the UI tries to open:

http://172.16.6.8:9999/layer/general/service

which results in "Layer not found".

In our setup, the correct URL should be:

http://172.16.6.8:9999/layer/general~/service

It seems that the ~ separator is missing from the generated URL when navigating from Topology → Open Service.

Other than this issue, the LDAP and access-control functionality has been working well in my testing.

Thanks again for the implementation. I’ll continue testing and will report any other issues I find.

[wu-sheng]

Thanks for testing with your LDAP and service-group setup, and for the report.

Topology → Open Service on a layer split by service group

This is a real bug, and it is fixed on main by apache/skywalking-horizon-ui#180, which the branch you built predates. On a split layer the link dropped the service group, so it opened a page that did not exist. It now opens the entry of the service's own group, including the entry for services with no group. The same fix covers API map on the map, Service → and Open endpoint on the API dependency graph, and Open in on the service hierarchy.

More split-layer fixes in apache/skywalking-horizon-ui#182

Looking into your report turned up more rough edges on split layers. They are fixed in #182, which is up for review and not merged yet:

• Layer page addresses changed. A service group's pages have plain addresses of their own, and a dashboard sub page moved under its own path. Old addresses are not redirected: after upgrading, update any bookmarks or links you keep outside Horizon, and any role landing page set in rbac.landingByRole.
• An overview widget placed on one service group now stores its layer the way a role grant names it, GENERAL[payments]. If you placed such a widget while testing, pick its layer again in the overview editor.
• The layer dashboards editor no longer lists a split layer's entries as extra layers.
• The 3D map places a split layer on its own tier, with its colour, traffic and hierarchy links.
• The Events button beside the picked service finds that service's events on a split layer, and the Continuous profiling picker shows each group's armed policies.

Everything is planned for 1.1.0. If you can test #182 against your setup, feedback there is very welcome.

[aliebrahimy]

Thanks for the detailed follow-up — and for chasing the Topology link issue down to a real bug. Good to hear #180 already covers it and the related links (API map, Open endpoint, hierarchy).