Feature Overview (aka. Goal Summary)  

An elevator pitch (value statement) that describes the Feature in a clear, concise way.  Complete during New status.

Deprecate the `ClusterExtension.spec.serviceAccount` field, make it optional in the API, and stop using it to scope the permissions that OLMv1 uses when lifecycling the ClusterExtension.

Goals (aka. expected user outcomes)

The observable functionality that the user now has as a result of receiving this feature. Include the anticipated primary user type/persona and which existing features, if any, will be expanded. Complete during New status.

1. Users will no longer be required to assign a serviceAccount on the ClusterExtension (the field will be marked as optional)
2. Users will no longer be confronted with permission errors during lifecycling events of the ClusterExtension
3. Users will no longer be required to follow the cumbersome permission creation procedure documented here: https://docs.redhat.com/en/documentation/openshift_container_platform/4.19/html-single/extensions/index#olmv1-cluster-extension-permissions_managing-ce
4. OLMv1 will be given cluster-admin permissions and use it's own permissions to lifecycle ClusterExtensions
5. Cluster Administrators will avoid giving write permission for ClusterExtensions to users who are not already Cluster Administrators.

Requirements (aka. Acceptance Criteria):

A list of specific needs or objectives that a feature must deliver in order to be considered complete.  Be sure to include nonfunctional requirements such as security, reliability, performance, maintainability, scalability, usability, etc.  Initial completion during Refinement status.

1. A new ClusterExtension can be created without providing `spec.serviceAccount`.
2. An existing ClusterExtension can be updated with a removal of the `spec.serviceAccount` field.
3. If `spec.serviceAccount` is provided, it must still include a valid `spec.serviceAccount.name`.
4. If a `spec.serviceAccount` is provided, OLMv1 ignores it.
5. OLMv1's service account is granted cluster-admin.
6. OLMv1 uses its service account for all interactions with the cluster's apiserver.
7. Code related to the feature-gated permissions preflight check is removed.

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.

Use Cases (Optional):

Include use case diagrams, main success scenarios, alternative flow scenarios.  Initial completion during Refinement status.

<your text here>

Questions to Answer (Optional):

Include a list of refinement / architectural questions that may need to be answered before coding can begin.  Initial completion during Refinement status.

1. Other than permissions bound to the service account, does OLM use anything else associated with it (e.g. service account secrets and imagePullSecrets)? If so, do we need to provide an alternative mechanism for users to provide these things to OLMv1?
2. Is it possible to actually remove the field without breaking existing clients?
   1. If a client sends a request that includes setting that field, will the request still succeed (and drop the spec.serviceAccount as a unknown field)?
   2. If a client using an old API definition deserializes a ClusterExtension that does not set `spec.serviceAccount` will the deserialization succeed? 
      1. If the deserialization succeeds do we expect existing clients to handle a missing service account?
   3. If so (or if we deem this issues unimportant), should we go ahead and remove the field?

Out of Scope

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

Building a replacement approval/policy engine is planned, but out-of-scope for this feature. 

Background

Provide any additional context is needed to frame the feature.  Initial completion during Refinement status.

Since 4.18, OLMv1 has required cluster administrators to provide a service account with each ClusterExtension, which OLMv1 uses to manage the lifecycle of the ClusterExtension. If the ServiceAccount lacks the necessary permissions, OLMv1 experiences permission failures at the time that a missing permission is needed.

The original intent of the feature was to provide a more secure system (OLMv1 itself has fewer direct permissions) and to be used as a policy mechanism to restrict ClusterExtensions from gaining new permissions automatically through updates.

However, there are a few problems with the mechanics of the feature:

1. The UX of creating a ServiceAccount with the necessary permissions is very difficult because the necessary permissions are only knowable once a bundle has been resolved and any user-provided configuration has been applied.
2. Users who have create permission on ClusterExtensions can create a ClusterExtension in a namespace that already contains a cluster-admin bound service account. This fact means that the ClusterExtension API can't be delegated to non-cluster admins in its current form.
3. OLMv1 itself needs to use the user-provided service account for somewhat internal purposes. For example, OLMv1's current implementation uses informers to provide an event stream for changes to OLMv1-managed operator manifests. This implementation detail leaks into user-required configuration, which causes fragility and complexity if/when OLM internal implementation details that require the service account change.

Customer Considerations

Provide any additional customer-specific considerations that must be made when designing and delivering the Feature.  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.

We should re-examine our documentation about configuring permissions, and likely simplify them greatly.

For example, this section (and surrounding sections): https://docs.redhat.com/en/documentation/openshift_container_platform/4.19/html-single/extensions/index#olmv1-cluster-extension-permissions_managing-ce

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>