Starting v17.2.5 RGW SSE with default key (likely others) no longer works
Hello Folks, I've been experimenting with RGW encryption and found this out. Focusing on Quincy and Reef dev, for the SSE (any methods) to work, transit has to be end to end encrypted, however if there is a proxy, then [1] can be made use to tell RGW that SSL is being terminated. As per docs, RGW can still continue to accept SSE if rgw_crypt_require_ssl is set to false as an overriding item for the requirement of encryption in transit. Below are my observations. Until v17.2.3 ( quay.io/ceph/ceph@sha256:43f6e905f3e34abe4adbc9042b9d6f6b625dee8fa8d93c2bae53fa9b61c3df1a), setting the same key as in [2], would show the object unreadable when copied using # rados -p default.rgw.buckets.data get 03c2ef32-b7c8-4e18-8e0c-ebac10a42f10.17254.1_file.plain file.enc The object would be unreadable. The original object is in plain text. Ofcourse, with rgw_crypt_require_ssl to false or [1] However, starting with v17.2.4 onwards and even until my recent testing with reef-dev (18.0.0-4353-g1e3835ab 1e3835abb2d19ce6ac4149c260ef804f1041d751) When I try getting the same object onto the disk using rados command, the object (contains plain text) would still be readable. Has something changed since v17.2.4? I'll also test with Pacific and let you know. Not sure if it affects other SSE mechanisms as well. [1] https://docs.ceph.com/en/quincy/radosgw/config-ref/#confval-rgw_trust_forwar... [2] https://docs.ceph.com/en/quincy/radosgw/encryption/#automatic-encryption-for... Thanks, Jayanth Reddy
On Sat, Jun 17, 2023 at 1:11 PM Jayanth Reddy <jayanthreddy5666@gmail.com> wrote:
Hello Folks,
I've been experimenting with RGW encryption and found this out. Focusing on Quincy and Reef dev, for the SSE (any methods) to work, transit has to be end to end encrypted, however if there is a proxy, then [1] can be made use to tell RGW that SSL is being terminated. As per docs, RGW can still continue to accept SSE if rgw_crypt_require_ssl is set to false as an overriding item for the requirement of encryption in transit. Below are my observations.
Until v17.2.3 ( quay.io/ceph/ceph@sha256:43f6e905f3e34abe4adbc9042b9d6f6b625dee8fa8d93c2bae53fa9b61c3df1a), setting the same key as in [2], would show the object unreadable when copied using # rados -p default.rgw.buckets.data get 03c2ef32-b7c8-4e18-8e0c-ebac10a42f10.17254.1_file.plain file.enc The object would be unreadable. The original object is in plain text. Ofcourse, with rgw_crypt_require_ssl to false or [1]
However, starting with v17.2.4 onwards and even until my recent testing with reef-dev (18.0.0-4353-g1e3835ab 1e3835abb2d19ce6ac4149c260ef804f1041d751) When I try getting the same object onto the disk using rados command, the object (contains plain text) would still be readable.
Has something changed since v17.2.4? I'll also test with Pacific and let you know. Not sure if it affects other SSE mechanisms as well.
[1] https://docs.ceph.com/en/quincy/radosgw/config-ref/#confval-rgw_trust_forwar... [2] https://docs.ceph.com/en/quincy/radosgw/encryption/#automatic-encryption-for...
Thanks, Jayanth Reddy _______________________________________________ ceph-users mailing list -- ceph-users@ceph.io To unsubscribe send an email to ceph-users-leave@ceph.io
hi Jayanth, 17.2.4 coincides with backports of the SSE-S3 and PutBucketEncryption features. those changes include a regression where the rgw_crypt_default_encryption_key configurable no longer applies. you can track the fix for this in https://tracker.ceph.com/issues/61473
participants (2)
-
Casey Bodley
-
Jayanth Reddy