Bug 1728985 - Disable Chargeback menu when user has no permission to view report
Summary: Disable Chargeback menu when user has no permission to view report
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: Management Console
Version: 4.2.0
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: ---
: 4.2.0
Assignee: David Taylor
QA Contact: Yadan Pei
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-07-11 07:12 UTC by Yadan Pei
Modified: 2019-11-01 18:17 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-10-16 06:33:27 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Github openshift console pull 2307 None None None 2019-08-08 18:47:13 UTC
Red Hat Product Errata RHBA-2019:2922 None None None 2019-10-16 06:33:39 UTC

Description Yadan Pei 2019-07-11 07:12:09 UTC
Description of problem:
Normal user visit Administration -> Chargeback page will get error

Version-Release number of selected component (if applicable):
4.2.0-0.nightly-2019-07-10-062553

How reproducible:
Always

Steps to Reproduce:
1. Normal user has access to Administration -> Chargeback page
2.
3.

Actual results:
1. Visiting Administration -> Chargeback page gives error message:
Error details
reportqueries.metering.openshift.io is forbidden: User "<user>" cannot list resource "reportqueries" in API group "metering.openshift.io" in the namespace "<usernamespace>"

Expected results:
1. Should disable Chargeback reports if user has no view permission for report

Additional info:

Comment 1 David Taylor 2019-07-15 20:34:27 UTC
Is this the desired fix?  I notice as a normal user if I goto Operators -> Operator Management, I see a similar message with the "Restricted Access" sign post.
"subscriptions.operators.coreos.com is forbidden: User "test" cannot list resource "subscriptions" in API group "operators.coreos.com" in the namespace "default"

Actually, I get the same  "Restricted Access" sign post going to any page under Workloads (Pods, Deployments, etc..).  Same for everything under Networking and Builds.

This seems to be the standard way we are handling this.

Comment 2 Samuel Padgett 2019-07-15 20:58:41 UTC
This is consistent with other places in console if the reports are namespaced.

We've made no RBAC changes to the left nav for any namespaced resource to this point. The problem is that you can switch between namespaces while staying on the same nav item. If we remove the item from the nav or disable it, things get a little weird if you're on the secrets page and change to a namespace where you have no access. It's also expensive since self-subject access reviews would require at least one request for every nav item for every namespace you select (and there are a lot of nav items).

We might want to try to do something if normal users aren't expected to be able to see chargeback reports, though.

Chance -- What users will be able to view these reports in a default install?

Comment 3 Samuel Padgett 2019-07-15 21:05:32 UTC
Talking to Chance, we might want to limit the UI to only get reports in openshift-metering. Then we can check specifically for the user's permissions in that namespace and hide the nav item appropriately. Most users won't be able to list these reports.

Comment 5 Yadan Pei 2019-08-27 07:27:32 UTC
Normal user can't view Administration -> Chargeback now, even cluster-reader. I will double confirm when a user is added into `reporting-readers` group

The original issue reported has been fixed, Verified on 4.2.0-0.nightly-2019-08-25-233755

Comment 6 errata-xmlrpc 2019-10-16 06:33:27 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2019:2922

Comment 7 Chance Zibolski 2019-11-01 18:17:47 UTC
No longer needs info, since we resolved in slack and this has been fixed in the release mentioned in the errata.


Note You need to log in before you can comment on or make changes to this bug.