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