Hi Milan- On Thu, 18 Jun 2015, Milan Broz wrote: > On 06/17/2015 06:16 AM, Sage Weil wrote: > >>> The wiki logins are broken, but ignore that.. we're moving to > >>> tracker.ceph.com's wiki shortly anyway. Email is best in the meantime! > >> > >> This proposal seems not have to have it to the new wiki. Is it still > >> alive? What do we need to do to keep this moving? > > I am not able to even login to wiki, seems logins are still completely broken. > Probably nobody can edit it now? The old wiki is frozen.. see the new wiki at http://tracker.ceph.com/projects/ceph/wiki (not much there yet). Jewel CDS blueprints are at http://tracker.ceph.com/projects/ceph/wiki/Jewel > > I can create a placeholder session. Can you two hash out a proposal over > > the next week or so to discuss? I think there are some tricky questions > > if petera is used if we want it to integrate with the monitors as well > > (e.g., leverage the monitors for updating/distributing the petera > > certs/keys). > > Yes, but later please. We have a lot of fun with selinux and other things, > this feature could follow later. > > BTW Petera is now renamed to Deo (and should be in Fedora packaged already). (Good to hear--petera had bad google mojo.) > The idea was: > > - use LUKS as the encryption format > > - use Deo to map OSD, for more info see > https://github.com/npmccallum/deo > > In short, Deo will connect to MON node and negotiate key and directly > unlock LUKS device. > (New version now uses libcryptsetup direcly, so it is really one client binary.) > > There must be a service listening on MONs nodes (Deo server). > > I have no idea yet how problematic will be handling certificates here, but > because it ensures authentication and encrypts communication, it seems like > a nice design. I think the ceph-mon piece is that we would need a monitor service that is responsible for storing/distributing the certs/keys. In order to make them visible to Deo, we'd need them to be stored in plaintext in a simple directory structure in /var/lib/ceph/mon/$cluster-$id/ somewhere. If we simply co-opt config-key to do this, or do this for a subset of the config-key namespace, this should be pretty simple. Do you know what the server-side file/directory should look like for Deo? > Anyway, delegating this task to one simple tool (maintained independently > of Ceph) is IMHO a good idea and the whole integration should not be complicated. > (Moreover it will allow easy integration with FreeIPA and similar tools later.) Yeah. My assumption is that this is essentially swapping out the bits that use the ceph mons to install keys? 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
