Feature Overview

ACM Observability RBAC Strategy: Three Levels of Access Control

Core Decision: We will focus in future on Perses for Dashboards.

The strategy is built upon three distinct levels of Role-Based Access Control (RBAC), with the general requirement that RBAC Levels 2 and 3 must also be enforceable via the Command Line Interface (CLI).

Level 1: Dashboard Management
Scope: RBAC to create, edit, and view Dashboard definitions.
Status: This requirement is largely satisfied. The native integration of Perses within the OpenShift Console already resolves most of the use cases for dashboard access.

Level 2: Data Scope Control (Cluster and Namespace)
Scope: RBAC to define which clusters and namespaces a user is permitted to view metrics from.
Current Functionality: This separation, working at the cluster-level or clusterset-level, has consistently proven effective within RHACM.
Future Direction: While the existing RHACM fine-grained RBAC (details here: https://docs.redhat.com/en/documentation/red_hat_advanced_cluster_management_for_kubernetes/2.14/html-single/observability/index#configure-fine-grain-rbac) can be utilized by both Grafana and Perses, it will not serve as our definitive long-term solution.
This might be considered
https://access.redhat.com/articles/7130526

Level 3: Metric Content Filtering
Scope: RBAC applied directly at the metrics level. This is crucial for use cases like Cost-Management, where certain metrics or specific metric labels should be hidden from unauthorized users.
Long-Term Solution: We plan to investigate integrating with authorization services such as SpiceDB and Kessel.
Workaround: We have an effective immediate solution with a prom-proxy (https://github.com/michaelalang/prom-proxy), which is compatible with Perses.

A Custom CR might be considered as also used by some customer

 
apiVersion: "observability.open-cluster-management.io/v1"
kind: ObservabilityAddonRole
metadata:
  name: example-mcoa-role
spec:
  actions:

• "metrics:read"
    scopes:
• any-label-you-want="any-label-value-you-want"

and then assign get access to the CR with kube-rbac to users:

rules:

• apiGroups: ["observability.open-cluster-management.io"]
    resources: ["ObservabilityAddonRole"]
    resourceNames: ["example-mcoa-role"]
    verbs: ["get"]

From Perses engineering:
We forward the current user token when querying metrics. So your backend should have the information to do the access check. RBAC in our context is only used to allow dashboard and datasource management, but the datasources (backends) are responsible for checking queries can be executed.
it's something that you want to implement at the backend API's level otherwise it would be easy to bypass Perses and get unlimited access to the metrics.

Requirements [TBD]

This Section: A list of specific needs or objectives that a Feature must
deliver to satisfy the Feature.. Some requirements will be flagged as MVP.
If an MVP gets shifted, the feature shifts. If a non MVP requirement slips,
it does not shift the feature.

(Optional) Use Cases [TBD]

This Section:

• Main success scenarios - high-level user stories
• Alternate flow/scenarios - high-level user stories
• ...

Questions to answer

• ...

Out of Scope

• …

Background, and strategic fit

This Section: What does the person writing code, testing, documenting
need to know? What context can be provided to frame this feature?

Assumptions

• ...

Customer Considerations

Documentation Considerations

Questions to be addressed:

• What educational or reference material (docs) is required to support this
  product feature? For users/admins? Other functions (security officers, etc)?
• Does this feature have a doc impact?
• New Content, Updates to existing content, Release Note, or No Doc Impact
• If unsure and no Technical Writer is available, please contact Content
  Strategy.
• What concepts do customers need to understand to be successful in
  [action]?
• How do we expect customers will use the feature? For what purpose(s)?
• What reference material might a customer want/need to complete [action]?
• Is there source material that can be used as reference for the Technical
  Writer in writing the content? If yes, please link if available.
• What is the doc impact (New Content, Updates to existing content, or
  Release Note)?