Dear Casey Thank you for the update and bug report. Best Regards Francois Scheurer ________________________________________ From: Casey Bodley <cbodley@xxxxxxxxxx> Sent: Tuesday, June 11, 2019 4:53 PM To: Scheurer François; ceph-users@xxxxxxxxxxxxxx Subject: Re: is rgw crypt default encryption key long term supported ? The server side encryption features all require special x-amz headers on write, so they only apply to our S3 apis. But objects encrypted with SSE-KMS (or a default encryption key) can be read without any x-amz headers, so swift should be able to decrypt them too. I agree that this is a bug and opened http://tracker.ceph.com/issues/40257. On 6/7/19 7:03 AM, Scheurer François wrote: > Hello Casey > > > We found something weird during our testing of the rgw_crypt_default_encryption_key=""xxx" parameter. > > s3cms behaves like expected: > s3cmd is then always writing encrypted objects > s3cmd can read encrypted and unencrypted objects > > but swift does not support encryption: > swift can read only unencrypted objects (encrypted objects return error md5sum != etag) > swift is not using encryption during writes (to demonstrate we can remove the rgw_crypt_default_encryption_key param and verify that the object is still readable). > > > Is that a bug? > > Thank you . > > > Cheers > Francois > > > ________________________________________ > From: Scheurer François > Sent: Wednesday, May 29, 2019 9:28 AM > To: Casey Bodley; ceph-users@xxxxxxxxxxxxxx > Subject: Re: is rgw crypt default encryption key long term supported ? > > Hello Casey > > > Thank you for your reply. > To close this subject, one last question. > > Do you know if it is possible to rotate the key defined by "rgw_crypt_default_encryption_key=" ? > > > Best Regards > Francois Scheurer > > > > ________________________________________ > From: Casey Bodley <cbodley@xxxxxxxxxx> > Sent: Tuesday, May 28, 2019 5:37 PM > To: Scheurer François; ceph-users@xxxxxxxxxxxxxx > Subject: Re: is rgw crypt default encryption key long term supported ? > > On 5/28/19 11:17 AM, Scheurer François wrote: >> Hi Casey >> >> >> I greatly appreciate your quick and helpful answer :-) >> >> >>> It's unlikely that we'll do that, but if we do it would be announced with a long deprecation period and migration strategy. >> Fine, just the answer we wanted to hear ;-) >> >> >>> However, I would still caution against using either as a strategy for >>> key management, especially when (as of mimic) the ceph configuration is >>> centralized in the ceph-mon database [1][2]. If there are gaps in our >>> sse-kms integration that makes it difficult to use in practice, I'd >>> really like to address those. >> sse-kms is working great, no issue or gaps with it. >> We already use it in our openstack (rocky) with barbican and ceph/radosgw (luminous). >> >> But we have customers that want encryption by default, something like SSE-S3 (cf. below). >> Do you know if there are plans to implement something similar? > I would love to see support for sse-s3. We've talked about building > something around vault (which I think is what minio does?), but so far > nobody has taken it up as a project. >> Using dm-crypt would cost too much time for the conversion (72x 8TB SATA disks...) . >> And dm-crypt is also storing its key on the monitors (cf. https://www.spinics.net/lists/ceph-users/msg52402.html). >> >> >> Best Regards >> Francois Scheurer >> >> >> Amazon SSE-3 description: >> >> https://docs.aws.amazon.com/AmazonS3/latest/dev/UsingServerSideEncryption.html >> Protecting Data Using Server-Side Encryption with Amazon S3-Managed Encryption Keys (SSE-S3) >> Server-side encryption protects data at rest. Amazon S3 encrypts each object with a unique key. As an additional safeguard, it encrypts the key itself with a master key that it rotates regularly. Amazon S3 server-side encryption uses one of the strongest block ciphers available, 256-bit Advanced Encryption Standard (AES-256), to encrypt your data. >> >> >> https://docs.aws.amazon.com/AmazonS3/latest/API/RESTBucketPUTencryption.html >> The following is an example of the request body for setting SSE-S3. >> <ServerSideEncryptionConfiguration xmlns="http://s3.amazonaws.com/doc/2006-03-01/";> >> <Rule> >> <ApplyServerSideEncryptionByDefault> >> <SSEAlgorithm>AES256</SSEAlgorithm> >> </ApplyServerSideEncryptionByDefault> >> </Rule> >> </ServerSideEncryptionConfiguration> >> >> >> >> >> >> >> >> >> ________________________________________ >> From: Casey Bodley <cbodley@xxxxxxxxxx> >> Sent: Tuesday, May 28, 2019 3:55 PM >> To: Scheurer François; ceph-users@xxxxxxxxxxxxxx >> Subject: Re: is rgw crypt default encryption key long term supported ? >> >> Hi François, >> >> >> Removing support for either of rgw_crypt_default_encryption_key or >> rgw_crypt_s3_kms_encryption_keys would mean that objects encrypted with >> those keys would no longer be accessible. It's unlikely that we'll do >> that, but if we do it would be announced with a long deprecation period >> and migration strategy. >> >> >> However, I would still caution against using either as a strategy for >> key management, especially when (as of mimic) the ceph configuration is >> centralized in the ceph-mon database [1][2]. If there are gaps in our >> sse-kms integration that makes it difficult to use in practice, I'd >> really like to address those. >> >> >> Casey >> >> >> [1] >> https://ceph.com/community/new-mimic-centralized-configuration-management/ >> >> [2] >> http://docs.ceph.com/docs/mimic/rados/configuration/ceph-conf/#monitor-configuration-database >> >> >> On 5/28/19 6:39 AM, Scheurer François wrote: >>> Dear Casey, Dear Ceph Users The following is written in the radosgw >>> documentation >>> (http://docs.ceph.com/docs/luminous/radosgw/encryption/): rgw crypt >>> default encryption key = 4YSmvJtBv0aZ7geVgAsdpRnLBEwWSWlMIGnRS8a9TSA= >>> >>> Important: This mode is for diagnostic purposes only! The ceph >>> configuration file is not a secure method for storing encryption keys. >>> >>> Keys that are accidentally exposed in this way should be >>> considered compromised. >>> >>> >>> >>> >>> Is the warning only about the key exposure risk or does it mean also >>> that the feature could be removed in future? >>> >>> >>> The is also another similar parameter "rgw crypt s3 kms encryption >>> keys" (cf. usage example in >>> http://lists.ceph.com/pipermail/ceph-users-ceph.com/2018-October/030679.html). >>> <http://lists.ceph.com/pipermail/ceph-users-ceph.com/2018-October/030679.html> >>> >>> >>> Both parameters are still interesting (provided the ceph.conf is >>> encrypted) but we want to be sure that they will not be dropped in future. >>> >>> >>> >>> >>> Best Regards >>> >>> Francois >>>
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ ceph-users mailing list ceph-users@xxxxxxxxxxxxxx http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
