[Feature] Expose -O encrypt format option

[mbrt]

Is your feature request related to a problem?/Why is this needed

In brief, we're in need to encrypt data at rest by using a per-tenant key, when storing customer data on EBS. We're currently thinking that the best way to fulfill this requirement is to use fscrypt, which works at the Kernel level and just requires the ext4 filesystem to be formatted with the -O encrypt option.

This option cannot be set at the StorageClass level with any option, as far as I can see.

/feature

Describe the solution you'd like in detail
FWIW, mount-utils supports arbitrary options to be passed to mkfs.ext4, so it would be just a matter of adding one more ext4 specific option to the storage class parameters.

This option could be plumbed through and passed to mount-utils similarly to other options (example here).

Describe alternatives you've considered
We've considered doing this on our own, basically through a DaemonSet that looks for EBS volumes mounted in the host that match certain characteristics, and call tune2fs -O encrypt /dev/device on them, but it sounds like a brittle solution.

Obviously this would be the first step, in order to get this to production, but ideally we hope that we can get rid of this workaround and rely on a first-class option in the StorageClass.

Additional context
More details about fscrypt here and [here]((https://github.com/google/fscrypt).

[ConnorJC3]

/type feature

Hi, thanks for the feature request! I can't promise anything firm at the moment but I will forward this to the team for evaluation.

Note that the EBS CSI Driver does support encrypting volumes via the kmsKeyId, which if passed the ARN of a KMS key will encrypt the volume at rest using EBS's built in encryption feature. You could use a KMS key per volume (and volume per tenant) to meet this requirement.

Also, if you must use fscrypt, rather than a DaemonSet I would suggest using the EBS CSI Driver's support for raw block volumes. This provides your pod with a block device that you can mount using whatever filesystem and parameters you want (for example using an init container).

[mbrt]

Thanks for the quick response!

You could use a KMS key per volume (and volume per tenant) to meet this requirement.

We actually considered this, but concluded that this would add scalability limitations to the number of tenants we can serve from a node and add constraints on the node type.

Good point about volumeMode: Block. I think this would be technically feasible, however this would not be fully transparent to engineering teams, as we would need to inject sidecars and change volume types. For context, we have ~90 applications multiplied by ~100 clusters, and I would like to minimize changes I ask our engineering teams to do. Ideally, this is something that works transparently at the platform layer.

I can't promise anything firm at the moment

If the team is on board with the feature, we can consider contributing it ourselves.