Note: Doc team updates the current version of the documentation and the
two previous versions (n-2), but we address *only high-priority, or
customer-reported issues* for -2 releases in support.
Describe the changes in the doc and link to your dev story:

1. - [x] Mandatory: Add the required version to the Fix version/s field.

2. - [x] Mandatory: Choose the type of documentation change or review.

• [ ] We need to update to an existing topic

• [ ] We need to add a new document to an existing section

• [x] We need a whole new section; this is a function not
  documented before and doesn't belong in any current section

• [ ] We need an Operator Advisory review and approval

• [ ] We need a z-Stream (Errata) Advisory and Release note
  for MCE and/or ACM

3. - [ ] *Mandatory: *Use the following link to open the doc and find where the
documentation update should go. Note: As the feature and doc is
understood and developed, this placement decision may change:

• Published doc: https://access.redhat.com/documentation/en-us/red_hat_advanced_cluster_management_for_kubernetes/2.10
• Source: https://github.com/stolostron/rhacm-docs

1. Observability What's new to include new technology preview of Fine-grain RBAC feature
https://github.com/stolostron/rhacm-docs/blob/2.11_stage/release_notes/whats_new.adoc#observability-whats-new

2. Create a new section "configuring fine-grain RBAC (Technology Preview) " under "Customizing Observability" section 
https://github.com/stolostron/rhacm-docs/blob/2.11_stage/observability/customize_observability.adoc

Content for this section:
========================

Fine-Grain RBAC (tech-preview) restricts metrics access to specific namespaces within the cluster, allowing application teams to view metrics only for the namespaces they are permitted to access.

Metrics access control is configured on the hub-cluster for hub users. Every managed-cluster is represented by a ManagedCluster custom resource object on the hub-cluster, and RBAC is specified through rules set up on these ManagedCluster resources and action verbs that indicate the namespaces allowed.

For example, 

• metrics/test specifies access to metrics collected from namespace test
• metrics/* specifies access to to metrics from all namespaces on the managed cluster

(NOTE: * is a special character indicator, and no other regular expressions are supported)

The existing managed-cluster level access control mechanism, which grants access to all metrics from a managed cluster by binding the 'admin' role to the managed cluster's project on the hub-cluster, is still supported for backward compatibility. However, when both cluster-level and namespace-level RBAC are configured for a given user, the namespace-level RBAC takes precedence. For example, if a user has both admin role access to the managed cluster's project and metrics/test access to the same managed cluster resource, the user can only access metrics from the test namespace on that managed cluster (most restrictive rule applies)

Consider an example scenario where an application my-awesome-app is provided on two managed clusters, namely devcluster1 and devcluster2. The application itself is deployed into two namespaces AwesomeAppNS1, AwesomeAppNS2 on these managed clusters. For simplicity, assume that both these namespaces exist on both managed clusters. 

Let’s assume that a user group my-awesome-app-admins  represents admin users for the app as defined below. We would like to make sure that these users are restricted to have access to metrics from these two namespaces only at the hub.

Step 1 : Define a ClusterRole with permissions to access metrics 

Step 2: Define a ClusterRoleBinding that binds admy-awesome-app-admins my-awesome-app-admins group with the awesome-app-metrics-role ClusterRole.

Note that if the namespaces between managed clusters are different, you must define separate cluster roles and cluster role bindings to represent each managed cluster.

When users from my-awesome-app-admins login into grafana:
1.  Dashboards  that summarize fleet-level data will show no data (empty). The expectation is that these users do not have the rights to see such data. For example, the following dashboards will show empty data.

• Cluster Overview dashboard
• Alerts Dashboard

2. Dashboards that allow selecting a managed cluster from a drop-down

• Only show the list of managed clusters specified in the cluster role
• Further, if the dashboards have a namespace selector, only namespaces specified in the ClusterRole(s)  will be available for the user to select.

4. - [x] Mandatory for GA content:

• [ ] Add steps, the diff, known issue, and/or other important
  conceptual information in the following space:

• [ ] *Add Required access level *(example, *Cluster
  Administrator*) for the user to complete the task:

• [ ] Add verification at the end of the task, how does the user
  verify success (a command to run or a result to see?)

• [x] Add link to dev story here: https://issues.redhat.com/browse/ACM-10865

5. - [ ] Mandatory for bugs: What is the diff? Clearly define what the
problem is, what the change is, and link to the current documentation. Only
use this for a documentation bug.