Re: [ceph-users] is rgw crypt default encryption key long term supported ?

[Scheurer François]

Dear Casey

Thank you for the update and bug report.

Best Regards
Francois Scheurer

From: Casey Bodley 
Sent: Tuesday, June 11, 2019 4:53 PM
To: Scheurer François; ceph-users@lists.ceph.com
Subject: Re: is rgw crypt default encryption key long term supported ?

The server side encryption features all require special x-amz headers on
write, so they only apply to our S3 apis. But objects encrypted with
SSE-KMS (or a default encryption key) can be read without any x-amz
headers, so swift should be able to decrypt them too. I agree that this
is a bug and opened http://tracker.ceph.com/issues/40257.

On 6/7/19 7:03 AM, Scheurer François wrote:
> 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@lists.ceph.com
> 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 
> Sent: Tuesday, May 28, 2019 5:37 PM
> To: Scheurer François; ceph-users@lists.ceph.com
> 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.
>> > xmlns="http://s3.amazonaws.com/doc/2006-03-01/";>
>> 
>>   
>>   AES256
>>   
>> 
>> 
>>
>>
>>
>>
>>
>>
>>
>>
>> 
>> From: Casey Bodley 
>> 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 o

Re: [ceph-users] is rgw crypt default encryption key long term supported ?

[Casey Bodley]

The server side encryption features all require special x-amz headers on 
write, so they only apply to our S3 apis. But objects encrypted with 
SSE-KMS (or a default encryption key) can be read without any x-amz 
headers, so swift should be able to decrypt them too. I agree that this 
is a bug and opened http://tracker.ceph.com/issues/40257.


On 6/7/19 7:03 AM, Scheurer François wrote:

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@lists.ceph.com
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 
Sent: Tuesday, May 28, 2019 5:37 PM
To: Scheurer François; ceph-users@lists.ceph.com
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.
http://s3.amazonaws.com/doc/2006-03-01/";>

  
  AES256
  











From: Casey Bodley 
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 = 4

Re: [ceph-users] is rgw crypt default encryption key long term supported ?

[Scheurer François]

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@lists.ceph.com
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 
Sent: Tuesday, May 28, 2019 5:37 PM
To: Scheurer François; ceph-users@lists.ceph.com
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.
>  xmlns="http://s3.amazonaws.com/doc/2006-03-01/";>
>
>  
>  AES256
>  
> 
> 
>
>
>
>
>
>
>
>
> 
> From: Casey Bodley 
> 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 a

Re: [ceph-users] is rgw crypt default encryption key long term supported ?

[Florian Engelmann]

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.
xmlns="http://s3.amazonaws.com/doc/2006-03-01/";>

   
 
 AES256
 











From: Casey Bodley 
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). 

 




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@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-u

Re: [ceph-users] is rgw crypt default encryption key long term supported ?

[Scheurer François]

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 
Sent: Tuesday, May 28, 2019 5:37 PM
To: Scheurer François; ceph-users@lists.ceph.com
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.
>  xmlns="http://s3.amazonaws.com/doc/2006-03-01/";>
>
>  
>  AES256
>  
> 
> 
>
>
>
>
>
>
>
>
> 
> From: Casey Bodley 
> 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).
>> 
>>
>>
>> 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
>>


smime.p7s
Description: S/MIME cryptographic signature
___
ceph-users mailing list
ceph-users

Re: [ceph-users] is rgw crypt default encryption key long term supported ?

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


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.
http://s3.amazonaws.com/doc/2006-03-01/";>
   
 
 AES256
 











From: Casey Bodley 
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).



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

Re: [ceph-users] is rgw crypt default encryption key long term supported ?

[Scheurer François]

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.
http://s3.amazonaws.com/doc/2006-03-01/";>
  

AES256


   









From: Casey Bodley 
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).
> 
>
>
> 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
>


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

Re: [ceph-users] is rgw crypt default encryption key long term supported ?

[Casey Bodley]

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




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

[ceph-users] is rgw crypt default encryption key long term supported ?

[Scheurer François]

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


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


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