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 <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-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@lists.ceph.com
http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com

Reply via email to