Skip to content
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Original file line number Diff line number Diff line change
Expand Up @@ -6,22 +6,28 @@
[id="granting-users-permission-to-monitor-user-defined-projects_{context}"]
= Granting users permission to monitor user-defined projects

Cluster administrators can monitor all core {product-title} and user-defined projects.
As a cluster administrator, you can monitor all core {product-title} and user-defined projects.

Cluster administrators can grant developers and other users permission to monitor their own projects. Privileges are granted by assigning one of the following monitoring roles:
You can also grant developers and other users different permissions:

* The *monitoring-rules-view* cluster role provides read access to `PrometheusRule` custom resources for a project.
* To monitor user-defined projects.
* To configure the components that monitor user-defined projects.
* To configure alert routing for user-defined projects.

* The *monitoring-rules-edit* cluster role grants a user permission to create, modify, and delete `PrometheusRule` custom resources for a project. It also grants a user the ability to silence alerts.
You can grant the permissions by assigning one of the following monitoring roles:

* The *monitoring-edit* cluster role grants the same privileges as the `monitoring-rules-edit` cluster role. Additionally, it enables a user to create new scrape targets for services or pods. With this role, you can also create, modify, and delete `ServiceMonitor` and `PodMonitor` resources.
|===
|Role name |Description

You can also grant users permission to configure the components that are responsible for monitoring user-defined projects:
|`monitoring-rules-view` | Users with this cluster role have read access to `PrometheusRule` custom resources for a user-defined project. They can also view the alerts in the *Developer* perspective of the {product-title} web console.

* The *user-workload-monitoring-config-edit* role in the `openshift-user-workload-monitoring` project enables you to edit the `user-workload-monitoring-config` `ConfigMap` object. With this role, you can edit the `ConfigMap` object to configure Prometheus, Prometheus Operator, and Thanos Ruler for user-defined workload monitoring.
|`monitoring-rules-edit` | Users with this cluster role can create, modify, and delete `PrometheusRule` custom resources for a user-defined project. They can also create and silence alerts in the *Developer* perspective of the {product-title} web console.

You can also grant users permission to configure alert routing for user-defined projects:
|`monitoring-edit` | Users with this cluster role have the same privileges as users with the `monitoring-rules-edit` cluster role. Additionally, users can create, modify, and delete `ServiceMonitor` and `PodMonitor` resources to scrape metrics from services and pods.

* The **alert-routing-edit** cluster role grants a user permission to create, update, and delete `AlertmanagerConfig` custom resources for a project.
|`user-workload-monitoring-config-edit` | This role is given in the `openshift-user-workload-monitoring` project. Users with this role can edit the `user-workload-monitoring-config` `ConfigMap` object to configure Prometheus, Prometheus Operator, Alertmanager, and Thanos Ruler for user-defined workload monitoring.

This section provides details on how to assign these roles by using the {product-title} web console or the CLI.
|`alert-routing-edit` | Users with this cluster role can create, update, and delete `AlertmanagerConfig` custom resources for a user-defined project.
|===

The following sections provide details on how to assign these roles by using the {product-title} web console or the CLI.