Thank you for the details. Very helpful to understand the state of this. I needed some more clarifications inline below: >This encryption only applies to object data. Other metadata, such as > object names, sizes and etags, are still visible to any client that can > GET the bucket listing or HEAD the objects. Just for clarification, does the "object data" imply block data too? and was this statement about the S3 only or also applies to Swift? >> It sounds like OSD to OSD traffic is unencrypted. >> >> 1) Does "stores data in the cluster in encrypted form" mean *only* if >> the --dmcrypt option is used? > >RGW server side encryption does not rely on the dmcrypt configuration >of the OSDs. For SSE-enabled objects, RGW will encrypt the object >data before sending it to OSDs, so unencrypted data is not sent over >Ceph's client/cluster networks. Got it, so --dmcrypt is basically on disk encryption of the OSDs and not related to any transport encryption. >> 2) Does that mean the zone to zone copy across a WAN is also >> unencrypted? >In a multisite configuration, SSE-enabled objects are replicated between >zones in their encrypted form. The same requirements for decryption >apply to both zones. I'm considering evaluating Swift integration with Ceph for multisite configuration. Does "and will not apply to the Swift protocol at all", mean there is no encryption between RGWs? (I wasn't sure if I even needed RGWs if Swift handles all the multisite traffic -- haven't looked into details yet) Or is there an implication that the Swift protocol itself could potentially now or in the future handle encrypted transport? thanks! On Mon, Oct 2, 2017 at 11:40 AM, Casey Bodley <cbodley@xxxxxxxxxx> wrote: > Hi, > > As this quoted text came from the RGW server-side encryption docs [1], I'll > add some details about that. > > First, this is an S3-only feature that implements two of Amazon's > specifications, SSE-C and SSE-KMS. For each upload, the S3 client must > specifically request server side encryption by providing extra headers for > each object upload. For example, you can do this with boto3 [2] by providing > a ServerSideEncryption with either a SSEKMSKeyId or > SSECustomerKey/SSECustomerAlgorithm when uploading an object. > > Because this encryption must be requested by the client on a per-object > basis, and will not apply to the Swift protocol at all, it can't be used to > provide blanket encryption for all radosgw object data. At best, a bucket > policy could require SSE-KMS encryption for all contained objects, but this > is not yet implemented in RGW. > > This encryption only applies to object data. Other metadata, such as object > names, sizes and etags, are still visible to any client that can GET the > bucket listing or HEAD the objects. > > > On 10/02/2017 02:18 AM, Two Spirit wrote: >>> >>> The Ceph Object Gateway supports server-side encryption of uploaded >>> objects, with 3 options for the management of encryption keys. Server-side >>> encryption means that the data is sent over HTTP in its unencrypted form, >>> and the Ceph Object Gateway stores that data in the Ceph Storage Cluster in >>> encrypted form. > > > While this says that data is sent over HTTP in its unencrypted form, the > Amazon specifications do require that SSE requests be made over an SSL > connection, and RGW does enforce this. > >> It sounds like OSD to OSD traffic is unencrypted. >> >> 1) Does "stores data in the cluster in encrypted form" mean *only* if >> the --dmcrypt option is used? > > > RGW server side encryption does not rely on the dmcrypt configuration of the > OSDs. For SSE-enabled objects, RGW will encrypt the object data before > sending it to OSDs, so unencrypted data is not sent over Ceph's > client/cluster networks. > >> >> 2) Does that mean the zone to zone copy across a WAN is also unencrypted? > > > In a multisite configuration, SSE-enabled objects are replicated between > zones in their encrypted form. The same requirements for decryption apply to > both zones. > >> -- >> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in >> the body of a message to majordomo@xxxxxxxxxxxxxxx >> More majordomo info at http://vger.kernel.org/majordomo-info.html > > > > [1] http://docs.ceph.com/docs/luminous/radosgw/encryption/ > [2] > http://boto3.readthedocs.io/en/latest/reference/services/s3.html#S3.Client.put_object -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
