Support granular server-side encryption in S3 with KMS keys (SSE-KMS)

[johanngan]

Context/use case

AWS KMS is AWS's managed cryptographic key service. It integrates with S3 ("SSE-KMS"), allowing server-side encryption of S3 objects at either the bucket-level (via bucket configuration) or at the object-level (using the x-amz-server-side-encryption-aws-kms-key-id HTTP header in certain requests).

Currently you can use both the S3 table engine and S3-backed MergeTree with an S3 bucket configured with bucket-level SSE-KMS without issue. However, (to my knowledge) there's no way for ClickHouse to do SSE-KMS at the object level, which means there's no way to, e.g., have different tables backed by the same S3 bucket but using different SSE-KMS keys (you might want to do this if you're mingling different data sources in a single database). It would be great if ClickHouse supported KMS key configuration for S3 endpoints/disks.

Describe the solution you'd like

ClickHouse already supports configuring SSE with customer-provided keys ("SSE-C") via the server_side_encryption_customer_key_base64 setting, which is supported both for the S3 table engine and S3-backed MergeTree; see #19748. Ideally, a solution for KMS would provide analogous settings corresponding to the various headers you can specify when configuring SSE-KMS:

• server_side_encryption_kms_key_id to specify a particular KMS key ID or alias for SSE, for example, "alias/my-kms-key".
• server_side_encryption_kms_encryption_context (corresponding to x-amz-server-side-encryption-context)
• server_side_encryption_kms_bucket_key_enabled (corresponding to x-amz-server-side-encryption-bucket-key-enabled)

Configuring these settings would cause ClickHouse to add (and sign) these headers to all relevant requests sent to S3.

Describe alternatives you've considered

1. The S3 table engine supports the header setting, so you might think to just specify the x-amz-server-side-encryption-aws-kms-key-id header manually. However, this doesn't work because S3 requires that the KMS header is signed, and the header setting is implemented in such a way that these custom headers are appended to the HTTP request post-signing. This setting also isn't implemented with S3 disks and so can't be used with S3-backed MergeTree.
2. You could just create separate buckets for every KMS key you want to use, and do all the configuration on the S3 side. But this is somewhat restrictive. For example, if you have many KMS keys, or many other buckets for other purposes, you may run into S3's per-account 100 bucket limit.