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
