Re: is rgw crypt default encryption key long term supported ?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Am 5/28/19 um 5:37 PM schrieb Casey Bodley:

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.

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

_______________________________________________
ceph-users mailing list
ceph-users@xxxxxxxxxxxxxx
http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com

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

[Index of Archives]     [Information on CEPH]     [Linux Filesystem Development]     [Ceph Development]     [Ceph Large]     [Ceph Dev]     [Linux USB Development]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [xfs]


  Powered by Linux