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? 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
