Hi, Thanks for this detailed response. ----- Original Message ----- > From: "Lars Marowsky-Bree" <lmb@xxxxxxxx> > To: "Ceph Development" <ceph-devel@xxxxxxxxxxxxxxx> > Sent: Tuesday, December 15, 2015 9:23:04 AM > Subject: Re: Improving Data-At-Rest encryption in Ceph > > It's not yet perfect, but I think the approach is superior to being > implemented in Ceph natively. If there's any encryption that should be > implemented in Ceph, I believe it'd be the on-the-wire encryption to > protect against evasedroppers. ++ > > Other scenarios would require client-side encryption. ++ > > > Cryptographic keys are stored on filesystem of storage node that hosts > > OSDs. Changing them require redeploying the OSDs. > > This is solvable by storing the key on an external key server. ++ > > Changing the key is only necessary if the key has been exposed. And with > dm-crypt, that's still possible - it's not the actual encryption key > that's stored, but the secret that is needed to unlock it, and that can > be re-encrypted quite fast. (In theory; it's not implemented yet for > the Ceph OSDs.) > > > > Data incoming from Ceph clients would be encrypted by primary OSD. It > > would replicate ciphertext to non-primary members of an acting set. > > This still exposes data in coredumps or on swap on the primary OSD, and > metadata on the secondaries. > > > Regards, > Lars > > -- > Architect Storage/HA > SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB > 21284 (AG Nürnberg) > "Experience is the name everyone gives to their mistakes." -- Oscar Wilde > -- -- Matt Benjamin Red Hat, Inc. 315 West Huron Street, Suite 140A Ann Arbor, Michigan 48103 http://www.redhat.com/en/technologies/storage tel. 734-707-0660 fax. 734-769-8938 cel. 734-216-5309 -- 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
