Feature Overview (aka. Goal Summary)  

In OCM feature https://issues.redhat.com/browse/XCMSTRAT-804, for the OCP clusters in AWS platform, user needs to specify the custom KMS key in StorageClass to encrypt the PVC. We have tried to update the StorageClass but the change will be reverted automatically by the csi driver operator. To make the change persistent, we have to update the CSIClusterDriver to set the spec.storageClassState as Unmanaged following https://docs.openshift.com/container-platform/4.16/storage/container_storage_interface/persistent-storage-csi-sc-manage.html

But this option is not elegant. We have to maintain the StorageClass, lose the management from the OCP cluster itself, and need to handle any incompatible changes in the future.

We need an option which exports the KMS key of the initial StorageClass(es), so that we can pass the KMS key for StorageClass. This option is similar as how the KMS key for one volume is exposed: https://github.com/openshift/hypershift/blob/main/api/hypershift/v1beta1/nodepool_types.go#L910

Possible changes for this:

• Changes to the operator API to allow supplying kms key arn for AWS platform
• Changes to CSI operator to pull the kms from the storage spec
• Changes to HyperShift to populate the kms key arn for storage operator spec, based on currently set kms key arn on hosted cluster spec

Goals (aka. expected user outcomes)

Users can specify custom KMS key of the initial StorageClass(es) through hypershift api for the OCP clustsers in AWS platform. So that the persistent volumes created using those StorageClass will be encrypted using the custom KMS key

Requirements (aka. Acceptance Criteria):

To be clear, the storage class that needs the KMS key is the one that a ROSA customer gets as their initial default storage class for their workloads (NOT the storage class for the control plane or management cluster).

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.

Customers that create a ROSA cluster from the classic architecture, expect to be able to pass a specific ARN identifying a AWS KMS key to encrypt the EBS storage that is used for their first StorageClass in the cluster that is used for customer workload persistent volumes.  We need to replicate the same experience for ROSA w/ Hosted Control Planes.

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.

<your text here>

Out of Scope

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

<your text here>

Background

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

<your text here>

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.

<your text here>

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>