Description
Is your feature request related to a problem?
Yes.
When creating a ROSA HCP cluster via rhcs_cluster_rosa_hcp, I can pass kms_key_arn (for worker-root volumes) and etcd_kms_key_arn (for control-plane etcd), but all dynamically-provisioned EBS volumes (e.g. prometheus-data-prometheus-k8s-0/1) still inherit the regional default KMS key /aws/ebs. This happens because the AWS EBS CSI driver’s default StorageClass (gp3-csi) is generated by the cluster after install and does not honour the cluster-level key settings (Managing the default storage class - Red Hat Documentation, Chapter 4. Configuring persistent storage - Red Hat Documentation).
Admins who require a customer-managed CMK for all data at rest must currently:
- manually create a new StorageClass with
parameters.kmsKeyId=<arn>(aws-ebs-csi-driver/docs/parameters.md at master - GitHub, Create a storage class - Amazon EKS - AWS Documentation) - mark it
storageclass.kubernetes.io/is-default-class: "true"or use the Storage Operator API to flip the default (Change the default StorageClass | Kubernetes, Dynamic provisioning | Storage | Red Hat OpenShift Service on AWS) - recreate every PVC, or rely on the retroactive default SC feature in ≥K8s v1.26 (Kubernetes v1.26: Retroactive Default StorageClass).
Automating this at cluster-create time would eliminate a post-install compliance gap.
Describe the solution you’d like
Add an optional argument (name suggestions: storage_kms_key_arn , default_storageclass_kms_key_arn, or a nested block under aws_settings) to rhcs_cluster_rosa_hcp.
-
Provider behaviour:
-
When set, the installer should hand the ARN to the hosted-control-plane operator, which would create/patch the initial AWS EBS CSI StorageClass (currently
gp3-csi) so thatparameters.encrypted=trueandparameters.kmsKeyId=<arn>. -
The StorageClass must be annotated
is-default-class: "true"so that operators such as openshift-monitoring automatically get encrypted PVCs from the outset (default kmsKeyID is not used when value is null #1267 - GitHub, Dynamic Volume Provisioning | Kubernetes). -
Validation: fail fast if the key is in a different Region or lacks the necessary EBS/Encrypt IAM grants.
This mirrors the pattern already available for worker-root and etcd keys, giving users a single-step, fully-encrypted install path.
Describe alternatives you’ve considered
| Alternative | Downsides |
|---|---|
Manual StorageClass creation via oc apply or bootstrap script |
Adds operational steps; easy to miss before PVCs are created |
| Account-level “EBS encryption by default” with the CMK set as regional default | Changes behaviour for all workloads in the AWS account; often blocked by platform teams |
| Retroactive default StorageClass feature in K8s ≥ 1.26 | Still requires post-install SC patch; feature gates vary by OpenShift/ROSA release |
Additional context / docs links
- AWS EBS CSI driver parameter
kmsKeyIdreference (aws-ebs-csi-driver/docs/parameters.md at master - GitHub) - Kubernetes docs on changing the default StorageClass (Change the default StorageClass | Kubernetes)
- ROSA doc: managing default storage class (states Managed/Unmanaged) (Managing the default storage class - Red Hat Documentation)
- ROSA doc: dynamic provisioning & default SC change procedure (Dynamic provisioning | Storage | Red Hat OpenShift Service on AWS)
- AWS docs: creating a StorageClass with CMK on EKS (identical parameters) (Create a storage class - Amazon EKS - AWS Documentation)
- Kubernetes blog: retroactive default StorageClass assignment (v1.26) (Kubernetes v1.26: Retroactive Default StorageClass)
- GitHub issue showing
/aws/ebsfallback when nokmsKeyIdsupplied (default kmsKeyID is not used when value is null #1267 - GitHub) - Kubernetes concept docs for StorageClass & dynamic provisioning (Storage Classes | Kubernetes, Dynamic Volume Provisioning | Kubernetes)
- OpenShift persistent-storage encryption doc (CMK option) (Chapter 4. Configuring persistent storage - Red Hat Documentation)
Thank you for considering this enhancement!