Am 5/28/19 um 5:37 PM schrieb Casey Bodley:
On 5/28/19 11:17 AM, Scheurer François wrote: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.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?
What about accepting empty HTTP header "x-amz-server-side-encryption" or "x-amz-server-side-encryption: AES256" if
rgw crypt default encryption key =is enabled. Even if this RadosGW "default encryption key" feature is not implemented the same way SSE-S3 is - still the data is encrypted by AES256. This would improve compatibility with the S3 API and client tools like s3cmd and awscli.
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.htmlThe 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 <cbod...@redhat.com> Sent: Tuesday, May 28, 2019 3:55 PM To: Scheurer François; ceph-users@lists.ceph.com 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-databaseOn 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 inhttp://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 isencrypted) but we want to be sure that they will not be dropped in future.Best Regards Francois_______________________________________________ ceph-users mailing list ceph-users@lists.ceph.com http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ ceph-users mailing list ceph-users@lists.ceph.com http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
