On 09/15/2012 06:54 AM, Sage Weil wrote:
Hey, A common requirement that's come up in conversation a few times now is on-disk, at-rest encryption. Usually, this is really just about making sure the bits on an individual disk are useless in isolation, so that drives can be safely discarded or RMAed without compromising customer data. I suspect the simplest way to accomplish this would be through something like dm-crypt. The trick would be keeping the keys for the osd's block device and journal elsewhere.
Sounds good to me. dm-crypt can use AES-NI which seems to help out a lot of the CPU usage front. It'd be nice to make sure it works.
One option would be to use the monitor as a lock box to securely store the disk encryption key, secured by the osd's existing cephx key is provided. The startup scripts (triggered via upstart, sysvinit, whatever) would need to get the keyring off the disk (separate, unencrypted partition?), get the disk key from the monitor, set up the dm-crypt devices, mount the osd's fs, and then start ceph-osd. An attacker in possession of a recovered disk would be need network connectivity to the cluster (prior to the keys getting revoked/destroyed) in order to decrypt it. Looking forward, another option might be to implement encryption inside btrfs (placeholder fields are there in the disk format, introduced along with the compression code way back when). This would let ceph-osd handle more of the key handling internally and do something like, say, only encrypt the current/ and snap_*/ subdirectories.
Sounds like this would make our code paths for btrfs and other filesystems diverge more rather than less. I like the idea of not making our startup scripts that much more complicated, but what we end up doing for xfs and others? Would we end up having to do the startup script path anyway or not support encryption on those FS?
Other ideas? Thoughts? sage -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
-- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
