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