Feature Overview

Today, the Governance user experience (UX) is primarily focused on policies (e.g., "Policy X is non-compliant on 4 clusters"). This feature introduces a new cluster-centric perspective, providing a dedicated view that allows users to assess their overall governance posture from the managed cluster level (e.g., "Cluster Y is violating 5 policies"). This provides a more operational, audit-driven workflow and enables powerful filtering based on cluster labels and attributes.

Goals

This Section: Provide high-level goal statement, providing user context
and expected user outcome(s) for this feature

• Primary Goal: Enable users to assess their governance posture from the perspective of their managed clusters and cluster sets.
• Expected Outcomes:
  • Users can quickly answer questions like: "What is the governance posture for all production clusters (env=prod)?"
    • e.g.; what is my governance posture for all clusters running on Azure?
    • e.g.; what is my governance posture for all OpenShift clusters running on 4.17 and below?
  • Users can easily identify and prioritize the most non-compliant clusters for remediation.
  • The overall Governance UX is unified and consistent across all policy types.

Requirements

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

This Section:

• Main success scenarios - high-level user stories:
  • Cluster Table: As a user, I can see a new list of my clusters, at a high-level, and understand the policy violation status.
    • Table Columns (Must be searchable, sortable, and filterable - should be comparable to main Clusters table):
      • Name (cluster name, clickable to details page)
      • Namespace (cluster namespace)
      • Cluster set (ManagedClusterSet, clickable)
      • Infrastructure (AWS, Azure, etc.)
      • Distribution version (OpenShift version)
      • # of policies in violation (Count of policies and their violation status, across all engines)
      • Cluster labels
      • Creation date
  • Drill-down User Flows:
    • Cluster Policy List: As a user, I can drill into a given cluster and see a list of all policies applied to it with their respective status.
      • Recommendation: This should be implemented as a new tab on the existing Infrastructure > Cluster details page (e.g., a "Governance" or "Policies" tab).
      • Table Columns (similar to Discovered Policies; support same sorting and filtering): Name (policy's name), Engine, Kind, Response action, Severity, Violations (Violations / No violations), Source.
    • Policy Details: As a user, I can drill into a given deployed policy on a specific cluster and see the policy details (same as the existing policy details page).

Questions to answer

• How does the user get to this page?
  • New tab in Governance?
  • New navigation item under Governance?
  • etc

Out of Scope

• Any changes to the policy enforcement engines (ConfigurationPolicy, Gatekeeper, etc.).
• Creation, editing, or deletion of policies from this new UI view.
• Defining new data collection or indexing logic (will use existing Search/Discovered Policies data).
• Replacement of the policy-centric view; this feature adds a complementary cluster-centric view.

Background, and strategic fit

Historically, the Governance UX was built around the Policy/PolicySet resource model, leading to a policy-centric view that is less effective for operational workflows. An operator's primary concern is often the health of their clusters. By shifting to a cluster-driven view, we are addressing a critical UX gap that will significantly improve how administrators monitor, audit, and prioritize remediation efforts. This change leverages the investment already made in the Discovered Policies feature, transforming raw data into actionable, cluster-focused intelligence. The strategic fit is to make RHACM a more intuitive and operations-friendly governance platform.

Assumptions

• All required policy status data (OCM, Gatekeeper, Kyverno, VAPB, etc.) is correctly indexed and available via the Search API.
• The data provided by the Search API is performant enough to support the sorting and filtering required for a large table of clusters.
• The product team agrees that the optimal placement is a new navigation item under the Governance section to keep the Infrastructure and Governance concerns separate.

Customer Considerations

• Reduced Time to Remediation: Administrators can quickly apply filters (e.g., env=prod) to identify non-compliant production clusters, speeding up auditing and response time.
• Improved Prioritization: The ability to sort by the number or severity of violations allows operators to prioritize the clusters that pose the highest risk.
• Consistent Experience: Unifying the view across multiple policy engines (OCM, Gatekeeper, Kyverno) simplifies the user's job.

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)?
  • Yes, for users/admins and security officers.
• Does this feature have a doc impact?
  • Unsure.
• 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]?
  • The difference between the Policy-centric and the new Cluster-centric Governance views, and how to use cluster labels to filter governance data.
• How do we expect customers will use the feature? For what purpose(s)?
  • To filter by cluster labels and versions to perform targeted violation audits and find the most non-compliant clusters.
• 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.
  • Yes, the existing policy documentation and the internal API specifications for the cluster table and Discovered Policies.
• What is the doc impact (New Content, Updates to existing content, or
  Release Note)?
  • Release Note.