Feature Overview

Goal is to enhance and granularize the access control model for KubeVirt and general workloads centrally managed by ACM, ensuring users/groups/sa have the necessary permissions across multiple clusters and projects.

ACM's multi-cluster management needs a more flexible way to determine precisely which KubeVirt (and later other) resources a user/group/sa is permitted to see, for example when using the ACM Search feature. Current access is often too broad or too restrictive for specific operational teams responsible for VM visibility.

We will create a new cluster-role which covers best practice permissions a Virt-Admin has but it is not easy to customize this and requires product-coding changes.

Let's take this example:

A user should be able to define this clusterroles and work in Fleet-Virtualization view to just get the results/permissions on the Hub.

Ideally a user should only reference those roles to the AggregatedAPI server just uses them.

Next Step: Implement and refine the logic within the Aggregated API Server to support more flexible and granular permission schemas for KubeVirt and other workloads.

Goals

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

• At the end there must be an easy intuitive way to configure this. A user should need to do quite nothing extra!!!

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
• 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)?