[Monitoring v2] Links in Dashboard are un-clickable even the user has monitoring-ui-view permission

[jiaqiluo]

Setup

• Rancher version: 2.6.2
• Browser type & version: Chrome, Version 95.0.4638.54 (Official Build) (x86_64)

Describe the bug

User who is assigned the clusterRole monitoring-ui-view Should be able to click and open the URLs for Altermamgne, Grafana, Prometheus and etc. in the Monitoring Dashboard page in Cluster Explorer

To Reproduce

Steps:

• as admin, create a downstream cluster and enable monitoring v2
• as admin, create a local user user1 and assign it to be project-member of a project p1 in the cluster
• as admin, create the clusterRoleBinding (monitoring-ui-view, user-1 )
• log in as user-1, go to the cluster explorer UI -> monitoring tab

Result

• links on the monitoring dashboard are greyed out and not clickable
• but user-1 can open the grafana/Prometheus/etc URLs provided by the admin

Expected Result

These Links should be available

Screenshots

There is one failed call in the traffic:

Request URL: https://xxx.xxx.xx.xx/k8s/clusters/c-7nm22/v1/endpoints/cattle-monitoring-system/rancher-monitoring-alertmanager
Request Method: GET
Status Code: 403 Forbidden

Getting the endpoint for Alertmanager in the cattle-monitoring-system namespace is not needed for showing the links. Somehow the UI is trying to get some unnecessary resources which makes the links unavailable?

---

Update 1:
New tests show that:
the UI works as expected (links are available) when the user is assigned the view monitoring role via the old cluster management UI, but does not work if create the clusterRoleBinding (monitoring-ui-view, user-1 ) via kubectl.
in both cases, UI sends a GET request to v1/endpoints/cattle-monitoring-system/rancher-monitoring-alertmanager and fail with 403 forbidden

[aiyengar2]

Identical to backend issue filed in rancher/rancher#35311.

[gaktive]

Internal reference: SURE-4075. Updated rancher/rancher#35311 too, where it feels like the bulk of the work would have to be done for monitoring.

[catherineluse]

What milestone should this be in?

[gaktive]

@catherineluse this is currently unscheduled though I'll sync up with @MKlimuszka since the related backend ticket shows more activity from the outside.

[gaktive]

Internal reference for docs: SURE-7044

and there's work to review the read-only permissions in the monitoring UI in SURE-7045 so there are limitations at present.

[mantis-toboggan-md]

Everything appears working as intended. A user with read-only project permission and the View Monitoring role shouldn't be able to use the links on the monitoring index (see rancher/rancher#43030 (comment)). With the fix in rancher/steve#132 visiting that page no longer causes a 500 error, the links are merely disabled as expected. I also confirmed that the workaround provided (moving the cattle-monitoring-system namespace) doesn't cause UI errors and the links become available.

[martyav]

This was labeled a release note but I'm having some difficulty parsing the comment thread. Can somebody provide a summary for the note?

[ronhorton]

A user with read-only project permission and the View Monitoring role shouldn't be able to use the links on the monitoring index (see rancher/rancher#43030 (comment)).

[martyav]

Let me put it another way: If the UI is behaving as intended when users with such-and-such permissions can't view the links, why do we also have a work-around to circumvent that? Do we want to release note a work-around that gets around the intended behavior?

[martyav]

From Slack

@MbolotSuse

My recommendation would be:
Release note that monitoring-ui-view permissions given through a clusteRroleBinding + read-only in a project is not sufficient for links to show up (known issue, I don't think we have an issue for this ATM)
Add the workaround in #4466 (comment) to the release notes for the issue (move the monitoring-system namespace into a project, give monitoring-ui-view in that project)

[Wizmll]

Hey guys, Im having a similar issue (the links in Dashboard are un-clickable) except that Im the admin (Default admin) of the k3s cluster ? Does anyone have any idea why? Thanks