Feature Overview (aka. Goal Summary)  

OLM v1 assists users in creating required ServiceAccounts with necessary permissions for managing cluster content lifecycle.

Goals (aka. expected user outcomes)

• Users can easily preview the required permissions before installing or upgrading an extension/operator.
• Users can create a ServiceAccount with OLM v1's guidance, ensuring it has the necessary permissions for installing or upgrading extensions/operators.

Background

By default, OLM v1 requires users to provide a service account for installing, upgrading, and deleting cluster content.  This aligns with the least privilege principle, as OLM v1's default service account is limited to granted permissions and cannot easily perform actions on behalf of users with lower privileges.

However, this requires cluster administrators or users with sufficient permissions to create a service account capable of creating, modifying, and deleting Kubernetes resources like Deployments, Services, and ConfigMaps, as needed by the extension/operator packages.

To simplify this process, OLM v1 aims to assist users in determining and creating service accounts with appropriate permissions to manage cluster content.

Requirements (aka. Acceptance Criteria)

• Required permissions analysis: OLM v1 analyzes an extension/operator bundle to determine the required permissions for its lifecycle management.
  • The required permissions include CRUD (Create, Read, Update, Delete) operations on all Kubernetes objects within the extension/operator bundle, as well as any permissions granted by included RBAC resources (if any) and resource dependencies.

• Required permissions preview: OLM v1 provides a preview of required permissions for installing or upgrading operators/extensions to users.

• Roles and RoleBindings creation: OLM v1 assists users in generating Role and RoleBinding objects based on the determined permissions, adhering to security best practices and least privilege principles.

• ServiceAccount creation: OLM v1 assists users in creating a ServiceAccount and associate it with the generated RoleBindings with appropriate permissions for installing or upgrading extensions/operators.
  • Provides an option for customizing the ServiceAccount name.

• User Interaction: OLM v1 offers guidance and options for users to review and modify the generated Role/RoleBinding/ServiceAccount before creation.
  • Provides an option for specifying custom permissions if needed.
  • Handles errors during Role/RoleBinding/ServiceAccount creation with retry.
  • Provides error messages for troubleshooting.

Anyone reviewing this Feature needs to know which deployment configurations that the Feature will apply to (or not) once it's been completed.  Describe specific needs (or indicate N/A) for each of the following deployment scenarios. For specific configurations that are out-of-scope for a given release, ensure you provide the OCPSTRAT (for the future to be supported configuration) as well.

Open Questions:

• How does this work for the contents packaged in Helm charts?  
  • Helm does not strictly require users to provide a ServiceAccount to create Kubernetes objects but can rely on the context in the Kubeconfig or the service account token mounted in the pod.  Should we follow that pattern as one of the options to streamline the UX?  

Out of Scope

High-level list of items that are out of scope.  Initial completion during Refinement status.

<your text here>

Documentation Considerations

Provide information that needs to be considered and planned so that documentation will meet customer needs.  If the feature extends existing functionality, provide a link to its current documentation. Initial completion during Refinement status.

• The steps for previewing the required permissions before installing or upgrading an extension/operator.
• The steps for creating a ServiceAccount and those associated Roles/Rolebindings with OLM v1's guidance, ensuring it has the necessary permissions for installing or upgrading extensions/operators.

Interoperability Considerations

Which other projects, including ROSA/OSD/ARO, and versions in our portfolio does this feature impact?  What interoperability test scenarios should be factored by the layered products?  Initial completion during Refinement status.

<your text here>