Bug 1973710

Created attachment 1792066 [details]
User permission

In OpenShift - and Kubernetes - there is no such concept of a "creator", and not such a concept of inherited ownership.
(There is a concpet of object ownership i.e. with operators and controllers, but this is not meant here).

Thus with this being said permissions are resembled around namespaces. Thus any user having access to the default namespace has access ot the objects within. Thus from this perspective to me this is not a bug.

Can you confirm that a unprivileged user can NOT read the metrics of VMs from an admin namespace (i.e. my-admin-namespace) that can not be accessed by the unprivileged user?

Changing to the monitoring component since it's not up to the console to do any RBAC checks. Console uses the user's token when it runs queries, and it's up to monitoring to do any access reviews.

Having said that, showing the empty role bindings tab for the user doesn't necessarily mean the user is unprivileged. I'm not sure the exact subject access review monitoring uses. Can you try the following command?

$ oc auth can-i get namespaces/default --all-namespaces

(In reply to Fabian Deutsch from comment #2)
> In OpenShift - and Kubernetes - there is no such concept of a "creator", and
> not such a concept of inherited ownership.
> (There is a concpet of object ownership i.e. with operators and controllers,
> but this is not meant here).
> 
> Thus with this being said permissions are resembled around namespaces. Thus
> any user having access to the default namespace has access ot the objects
> within. Thus from this perspective to me this is not a bug.
> 
> Can you confirm that a unprivileged user can NOT read the metrics of VMs
> from an admin namespace (i.e. my-admin-namespace) that can not be accessed
> by the unprivileged user?

I agree with Fabian here.

The monitoring components do check RBAC for metric queries. Waiting for the needinfo, but I suspect this is NOTABUG.

The kube-rbac-proxy service in front of the Thanos querier verifies that the user has permissions to get pods metrics in the given namespace [1]. If so the user can query any metric in the namespace. As already said above, no rolebinfings doesn't mean that the user is unprivileged (otherwise access to the console wouldn't be possible).

[1] https://github.com/openshift/cluster-monitoring-operator/blob/625f9341aaa0f74b84dfc5cc132a83305cb97432/assets/thanos-querier/kube-rbac-proxy-secret.yaml#L14-L18

Please note: I am currently waiting on a 4.8 cluster to verify output of `oc auth can-i get namespaces/default --all-namespaces`. I will update this bug, as soon as I can collect that information.

Based on comment #5, it looks like we check specifically for pod access. I'd check

$ oc auth can-i get pods -n default

Here is the output:
(cnv-tests) [cnv-qe-jenkins@infra-debug1b-85zrr-executor cnv-tests]$ oc auth can-i get pods -n default --as=unprivileged-user
no
(cnv-tests) [cnv-qe-jenkins@infra-debug1b-85zrr-executor cnv-tests]$ 

Please note: With further triaging on this, I was able to isolate the issue to be only relevant to UI option to Impersonate a user. This may not be just applicable to `key metrics` however. This is reproducible consistently on firefox and chrome -only with the following steps.
Create an unprivileged user
Steps:
1) login as kubeadmin
2) Open Administrator> User management> Users > Impersonate User unprivileged user
3) this loads the browser logged in as unprivileged user and switches to Developer perspective.
4) At this point open monitoring and note, we can not load "default" namespace - only option available for Projects dropdown is: "Openshift-virtualization-os-images".

Now go back to step 1 by logging out and re-login as kubeadmin. Access "default" namespace as kubeadmin(Administrator>Administration>Namespaces>"default") and repeat steps 2-4, now I can see by default the monitoring page has Project "default" selected. From this point. I can make any key metrics query.


Will be attaching screenshots.

Also note: this works as expected, if instead of "Impersonate User", I actually login with the same user credentials.

I agree this seems like a console issue.
Using `oc adm top pods` as a test I can confirm that an unprivileged user can not query metrics through the k8s API. Hitting the prometheus query interface directly requires an authorization token as well.

Reassigning to the console team.

Impersonation does not work for metrics requests since it relies on the k8s API impersonation headers, and those aren't supported for Prometheus queries. I don't think we can fix this in console alone aside from maybe disabling all metrics when impersonation is active.

Note that there is no security exposure here since you're actually logged in as a user with authority to see those charts.

In the admin console, we hide the whole "Monitoring" section from the sidebar, so I think this is just a UX issue for the dev console. Perhaps the dev console should also hide some of those links from the navigation?

Can we get an update from the Dev Console team please?

Thanks Samuel. Christian, when can I expect this bug to be fixed?

Hi, I assume this won't be addressed in 4.11?
Please update the target release.

I have not been able to reproduce this issue against 4.11 cluster. As vikram mentioned, as an unprivileged user, I am no longer able to see metrics options.

Based on the comments this is fixed in 4.11.

@viraj can you add a PR link to this ticket?

@dbasunag Is there a need to backport this to 4.10 or 4.9?

I close this, for now, please let us know if some additional info or steps are needed from our side.

Looks like it has been fixed by this PR https://github.com/openshift/console/pull/9362

Marking verified in 4.11.6 per comment 32

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 (OpenShift Container Platform 4.11.6 bug fix update), 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-2022:6659

The needinfo request[s] on this closed bug have been removed as they have been unresolved for 120 days