OCPSTRAT-1679: enhancement: StorageClass KMS Key for AWS Hosted Control Planes by devguyio · Pull Request #2039 · openshift/enhancements

devguyio · 2026-06-15T08:53:04Z

Add enhancement proposal for customer-controlled default encryption of
guest-cluster EBS volumes using a specified KMS key in HyperShift AWS
hosted control planes.

This closes a parity gap between ROSA classic and ROSA HCP for storage
encryption by adding storageKMSKeyARN to AWSPlatformSpec, propagating
it through the HC controller → HCCO → ClusterCSIDriver chain, and
exposing a --storage-volumes-kms-key CLI flag.

Tracking: OCPSTRAT-1679
Related: openshift/enhancements#1163

cc @csrwng @muraee @celebdor @enxebre

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> Signed-off-by: Ahmed Abdalla <aabdelre@redhat.com>

openshift-ci-robot · 2026-06-15T08:54:02Z

@devguyio: This pull request references OCPSTRAT-1679 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the feature to target either version "5.0." or "openshift-5.0.", but it targets "openshift-5.1" instead.

Details

In response to this:

Add enhancement proposal for customer-controlled default encryption of
guest-cluster EBS volumes using a specified KMS key in HyperShift AWS
hosted control planes.

This closes a parity gap between ROSA classic and ROSA HCP for storage
encryption by adding storageKMSKeyARN to AWSPlatformSpec, propagating
it through the HC controller → HCCO → ClusterCSIDriver chain, and
exposing a --storage-volumes-kms-key CLI flag.

Tracking: OCPSTRAT-1679
Related: openshift/enhancements#1163

cc @csrwng @muraee @celebdor @enxebre

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

openshift-ci · 2026-06-15T08:54:42Z

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign enxebre for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

enhancements/hypershift/OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

openshift-ci · 2026-06-15T09:13:33Z

@devguyio: all tests passed!

Full PR test history. Your PR dashboard.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here.

devguyio · 2026-06-15T09:16:49Z

/cc @celebdor @enxebre

enxebre · 2026-06-15T09:51:40Z

+
+## Motivation
+
+ROSA classic clusters allow customers to configure KMS encryption for volumes created


can we elaborate how rosa classic leverage this semantic, and how rosa hcp is planning to do the same, e.g. is there any efforts we can link to expose this in ocm?

enxebre · 2026-06-15T09:51:46Z

+  cluster (day-2 operation) so that new PVCs use an updated or rotated KMS key without
+  requiring cluster recreation.
+
+- As a self-managed HyperShift operator on AWS, I want to specify a KMS key for the


"hypershift" is a dev cli, "hcp" is product one. Let's remove any ambiguity so we get agents straight

enxebre · 2026-06-15T09:52:31Z

+
+### Goals
+
+- Add `storageKMSKeyARN` to `AWSPlatformSpec` (shared by `HostedCluster` and


I think storageKMSKeyARN should belong to parent api struct that can potentially grow cohesively

enxebre · 2026-06-15T09:53:18Z

+approvers:
+  - "@csrwng"
+  - "@enxebre"
+api-approvers:


please let's include here @JoelSpeed @everettraven so we diversify knowledge

enxebre · 2026-06-15T09:54:34Z

+title: storageclass-kms-key
+authors:
+  - "@devguyio"
+reviewers:


please let's include here managed services and storage representatives so we diversify knowledge
cc @joshbranham, @jsafrane

enxebre · 2026-06-15T09:57:30Z

+   reads this value and configures the default StorageClass with the KMS key ID.
+5. New EBS volumes provisioned via the StorageClass carry the KMS encryption.
+
+When the field is cleared, the HCCO clears `DriverConfig.AWS.KMSKeyARN`, the CSO reverts


There needs to be a way to opt-out from reconciliation so in cluster changes UX is preserved, is this how you achieve that?

enxebre · 2026-06-15T11:30:50Z

+
+1. The HC controller mirrors the field to `HostedControlPlane.spec.platform.aws.storageKMSKeyARN`,
+   following the existing mirroring pattern for other `AWSPlatformSpec` fields.
+2. The HCCO validates the key by assuming the `StorageARN` role (already provisioned for


is 2 something that the storage does today? If not, should that be an epic for storage operator?

enxebre · 2026-06-15T11:31:55Z

+   the HC controller bubbles it to `HostedCluster` status.
+4. The HCCO storage reconciliation writes `ClusterCSIDriver.spec.driverConfig.aws.kmsKeyARN`
+   to the guest cluster via its guest cluster client. The cluster-storage-operator (CSO)
+   reads this value and configures the default StorageClass with the KMS key ID.


does introduces a race for stateful workloads using the default class? can we outline the risks of that?

jsafrane · 2026-06-15T12:09:29Z

+- **Per-StorageClass KMS key granularity.** This enhancement targets only the default
+  StorageClass managed by the cluster-storage-operator. The CSI operator's
+  `ClusterCSIDriver.DriverConfig` applies to the driver globally; per-StorageClass


Users can still create their own StorageClasses with their own keys, at least on standalone clusters. The enhancement affects only the default StorageClasses.

csrwng · 2026-06-15T16:00:45Z

+
+## Proposal
+
+When a customer sets `spec.platform.aws.storageKMSKeyARN` on a `HostedCluster`, the


So far the pattern for operator configs is to place them under hc.spec.operatorConfiguration. Would this not be better under something like: hc.spec.operatorConfiguration.csiDrivers.ebs = {blah} ?

ebs may not be the only csi driver for the aws platform (afaik for aws there is at least efs and s3 as well)

Echoing Cesar's (and Alberto's points above), this should probably have additional nesting instead of just a subfield in spec.platform.aws.

On the point of

nesting adds indirection with no benefit. A nested struct can be introduced in a follow-on enhancement if additional storage fields are needed.

below, this is not really true. APIs are hard to modify after creation especially in OCP, as we retain support for a major release's lifecycle, so we should consider future API additions in the design.

It's probably overkill but the direct equivalent would probably be something like hc.spec.operatorConfiguration.csiDriverConfig.aws.kmsKeyARN

enxebre · 2026-06-16T15:17:43Z

+
+## Summary
+
+This enhancement adds an optional `storageKMSKeyARN` field to the AWS platform spec


will existing iam policies support encryption?

yuqi-zhang

Adding some comments from the openshift/api perspective

yuqi-zhang · 2026-06-23T00:25:21Z

+
+## Proposal
+
+When a customer sets `spec.platform.aws.storageKMSKeyARN` on a `HostedCluster`, the


Echoing Cesar's (and Alberto's points above), this should probably have additional nesting instead of just a subfield in spec.platform.aws.

On the point of

nesting adds indirection with no benefit. A nested struct can be introduced in a follow-on enhancement if additional storage fields are needed.

below, this is not really true. APIs are hard to modify after creation especially in OCP, as we retain support for a major release's lifecycle, so we should consider future API additions in the design.

It's probably overkill but the direct equivalent would probably be something like hc.spec.operatorConfiguration.csiDriverConfig.aws.kmsKeyARN

yuqi-zhang · 2026-06-23T00:26:23Z

+StorageKMSKeyARN string `json:"storageKMSKeyARN,omitempty"`
+```
+
+The field is validated with a CEL `XValidation` rule accepting both KMS key ARNs and


Let's add these following points directly to the validation above, i.e..

// +optional // +kubebuilder:validation:MaxLength=2048 // +kubebuilder:validation:XValidation:rule="...",message="..." StorageKMSKeyARN string `json:"storageKMSKeyARN,omitempty"`

yuqi-zhang · 2026-06-23T00:31:30Z

+alias ARNs:
+
+```text
+^arn:(aws|aws-cn|aws-us-gov):kms:[a-z0-9-]+:[0-9]{12}:(key|alias)/[a-zA-Z0-9:/_-]+$


I assume this is the hypershift equivalent of https://github.com/openshift/api/blob/master/operator/v1/types_csi_cluster_driver.go#L176, perhaps we can see if matching the validation and godocs there makes sense

yuqi-zhang · 2026-06-23T00:32:59Z

+
+**Day-2 (key removal):**
+
+1. The administrator sets `storageKMSKeyARN` to empty string.


Technically conflicts with the field being optional and omitempty. The right user behaviour is deleting the field. Empty string should not be allowed since there's no difference between that and an unset field.

yuqi-zhang · 2026-06-23T00:33:45Z

+// Updating this field does not re-encrypt existing volumes; only newly
+// created PVCs use the new key.
+// +optional
+StorageKMSKeyARN string `json:"storageKMSKeyARN,omitempty"`


Not sure how far we got with featuregating in hypershift, but this might be a good candidate for one.

yuqi-zhang · 2026-06-23T00:35:54Z

+2. The HC controller updates the `HostedControlPlane` field; the HCCO re-validates and
+   updates `ClusterCSIDriver`.
+3. The CSO updates the default StorageClass. There is a brief period between CSO
+   reconciliation cycles where the StorageClass references neither the old nor the new


A bit confused on this point, how would it be neither? I thought it would just be using the old key until reconciliation, and there's no "gap" period.

yuqi-zhang · 2026-06-23T00:38:50Z

+include the `alias/` ARN resource type and the broader alias name character set
+(`:`, `/`, `_` are valid in alias names).
+
+#### New condition type: `ValidAWSStorageKMSConfig`


I'm not familiar with general hypershift status/conditions, but just thinking from a user perspective, let's say I updated my key, I don't think there's a easy way to see if/when that gets applied just by looking at the conditions, since it doesn't actually tell me what the last success was.

Would there be an equivalent status field we could populate for the last successful key reconciliation?

enhancement: StorageClass KMS Key for AWS Hosted Control Planes

9b3e8a5

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> Signed-off-by: Ahmed Abdalla <aabdelre@redhat.com>

devguyio changed the title ~~enhancement: StorageClass KMS Key for AWS Hosted Control Planes~~ OCPSTRAT-1679: enhancement: StorageClass KMS Key for AWS Hosted Control Planes Jun 15, 2026

openshift-ci-robot added the jira/valid-reference Indicates that this PR references a valid Jira ticket of any type. label Jun 15, 2026

openshift-ci Bot requested review from csrwng and sjenning June 15, 2026 08:54

openshift-ci Bot requested review from celebdor and enxebre June 15, 2026 09:16

enxebre reviewed Jun 15, 2026

View reviewed changes

jsafrane reviewed Jun 15, 2026

View reviewed changes

csrwng reviewed Jun 15, 2026

View reviewed changes

enxebre reviewed Jun 16, 2026

View reviewed changes

yuqi-zhang reviewed Jun 23, 2026

View reviewed changes


		## Motivation

		ROSA classic clusters allow customers to configure KMS encryption for volumes created


		### Goals

		- Add `storageKMSKeyARN` to `AWSPlatformSpec` (shared by `HostedCluster` and


		## Proposal

		When a customer sets `spec.platform.aws.storageKMSKeyARN` on a `HostedCluster`, the


		## Summary

		This enhancement adds an optional `storageKMSKeyARN` field to the AWS platform spec


		Day-2 (key removal):

		1. The administrator sets `storageKMSKeyARN` to empty string.

Uh oh!

Conversation

devguyio commented Jun 15, 2026

Uh oh!

openshift-ci-robot commented Jun 15, 2026 • edited by openshift-ci Bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

openshift-ci Bot commented Jun 15, 2026

Uh oh!

openshift-ci Bot commented Jun 15, 2026

Uh oh!

devguyio commented Jun 15, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

enxebre Jun 15, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

yuqi-zhang left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

8 participants

openshift-ci-robot commented Jun 15, 2026 •

edited by openshift-ci Bot

Loading

enxebre Jun 15, 2026 •

edited

Loading