Bug 1947005
Summary: | cluster-monitoring-view role allows to create alert silences | ||
---|---|---|---|
Product: | OpenShift Container Platform | Reporter: | German Parente <gparente> |
Component: | Monitoring | Assignee: | Prashant Balachandran <pnair> |
Status: | CLOSED ERRATA | QA Contact: | Junqi Zhao <juzhao> |
Severity: | low | Docs Contact: | |
Priority: | unspecified | ||
Version: | 4.7 | CC: | anpicker, dgrisonn, erooth, hongyli, lbarbeev, lcosic, malonso, pnair, spasquie |
Target Milestone: | --- | Keywords: | EasyFix |
Target Release: | 4.9.0 | Flags: | pnair:
needinfo-
|
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: |
Cause: cluster-monitoring-view role is a generic role within monitoring.
Consequence: this allows alerts to be silenced and created. As the role named cluster-monitoring-view, it should not allow any write operation.
Fix: adding a new role monitoring-alertmanager-edit. The following commands can be used to allow users to access the alert manager.
oc adm policy add-cluster-role-to-user cluster-monitoring-view user1
oc adm policy add-role-to-user monitoring-alertmanager-edit user1 -n openshift-monitoring --role-namespace openshift-monitoring
Result: This role will now be required to silence and create alerts in addition to cluster-monitoring-view role.
|
Story Points: | --- |
Clone Of: | Environment: | ||
Last Closed: | 2021-10-18 17:29:50 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
German Parente
2021-04-07 13:39:54 UTC
tested with 4.9.0-0.nightly-2021-07-18-155939, login alertmanager UI with cluster-monitoring-view user get 403 Permission Denied now, which is inconsistent with former behaviour, no such issue with other monitoring UIs $ oc adm policy add-cluster-role-to-user cluster-monitoring-view juzhao1 $ oc -n openshift-monitoring logs -c alertmanager-proxy alertmanager-main-0 ... 2021/07/19 07:31:57 provider.go:627: 200 GET https://172.30.0.1/apis/user.openshift.io/v1/users/~ {"kind":"User","apiVersion":"user.openshift.io/v1","metadata":{"name":"juzhao1","uid":"5948ce6a-3131-4fab-9ae8-404a8ba031c3","resourceVersion":"220581","creationTimestamp":"2021-07-19T07:24:43Z","managedFields":[{"manager":"oauth-server","operation":"Update","apiVersion":"user.openshift.io/v1","time":"2021-07-19T07:24:43Z","fieldsType":"FieldsV1","fieldsV1":{"f:identities":{}}}]},"identities":["Script-Htpassidp:juzhao1"],"groups":["system:authenticated","system:authenticated:oauth"]} 2021/07/19 07:31:57 provider.go:627: 201 POST https://172.30.0.1/apis/authorization.openshift.io/v1/subjectaccessreviews {"kind":"SubjectAccessReviewResponse","apiVersion":"authorization.openshift.io/v1","allowed":true,"reason":"RBAC: allowed by ClusterRoleBinding \"cluster-monitoring-view\" of ClusterRole \"cluster-monitoring-view\" to User \"juzhao1\""} 2021/07/19 07:31:57 provider.go:627: 201 POST https://172.30.0.1/apis/authorization.openshift.io/v1/subjectaccessreviews {"kind":"SubjectAccessReviewResponse","apiVersion":"authorization.openshift.io/v1","namespace":"openshift-monitoring","allowed":false} 2021/07/19 07:31:57 provider.go:478: Permission denied for juzhao1 for check {"namespace":"openshift-monitoring","resource":"alertmanagers","resourceAPIGroup":"monitoring.coreos.com","resourceName":"non-existant","scopes":[],"verb":"patch"} 2021/07/19 07:31:57 oauthproxy.go:650: 10.128.2.11:56858 Permission Denied: user is unauthorized when redeeming token 2021/07/19 07:31:57 oauthproxy.go:445: ErrorPage 403 Permission Denied Invalid Account Ideally only the cluster admin needs access to the alert manager UI. Anybody else with just cluster-monitoring-view permissions need not have access as the only reason to go there is to create and suppress alerts. These actions are write operations and should not be available with just view permissions. cluster-monitoring-view user can not see the silences in console UI and can't login the alertmanager UI(403 error) now. but monitoring-alertmanager-edit is only a role, not a clusterrole "oc adm policy add-role-to-user" is add the role to users or service accounts for one project. # oc adm policy add-role-to-user --help Add a role to users or service accounts for the current project. the monitoring-alertmanager-edit user can not login with neither the alertmanager UI(403 error) nor console UI. (In reply to Junqi Zhao from comment #20) > the monitoring-alertmanager-edit user can not login with neither the > alertmanager UI(403 error) nor console UI. login console with monitoring-alertmanager-edit user, there is not "Observe" navigation bar in the left and can't view any resources under user namespaces checked with 4.9.0-0.nightly-2021-07-21-081948, and grant admin/cluster-monitoring-view/monitoring-alertmanager-edit roles to user # oc adm policy add-cluster-role-to-user cluster-monitoring-view testuser-11 # oc adm policy add-cluster-role-to-user admin testuser-11 # oc adm policy add-role-to-user monitoring-alertmanager-edit testuser-11 -n openshift-monitoring user can login alertmanager UI and console UI, user can silent alerts and check alerts on console UI note: for # oc adm policy add-role-to-user monitoring-alertmanager-edit testuser-11 -n openshift-monitoring there is one bug now, see bug 1984904, you can update manually to the correct value then test Thanks for the update Junqi! The following command would also create the correct role binding: oc adm policy add-role-to-user monitoring-alertmanager-edit user1 -n openshift-monitoring --role-namespace openshift-monitoring Prashant, could you update the doc text to describe the exact commands to be executed for granting Alertmanager access to a user? 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 (Moderate: OpenShift Container Platform 4.9.0 bug fix and security 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/RHSA-2021:3759 |