From: Sage Weil <sage@newdream.net>
To: Milan Broz <mbroz@redhat.com>
Cc: Andrew Bartlett <abartlet@catalyst.net.nz>, ceph-devel@vger.kernel.org
Subject: Re: Interested in ceph OSD encryption and key management
Date: Thu, 18 Jun 2015 07:31:05 -0700 (PDT) [thread overview]
Message-ID: <alpine.DEB.2.00.1506180716260.23826@cobra.newdream.net> (raw)
In-Reply-To: <5582C8F2.2010604@redhat.com>
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
prev parent reply other threads:[~2015-06-18 14:31 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-28 4:23 Interested in ceph OSD encryption and key management Andrew Bartlett
2015-05-28 20:03 ` Sage Weil
2015-05-31 14:01 ` Wyllys Ingersoll
2015-06-03 0:07 ` Andrew Bartlett
2015-06-03 0:12 ` Andrew Bartlett
2015-06-03 5:39 ` Milan Broz
2015-06-17 2:37 ` Andrew Bartlett
2015-06-17 4:16 ` Sage Weil
2015-06-18 13:34 ` Milan Broz
2015-06-18 14:31 ` Sage Weil [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.DEB.2.00.1506180716260.23826@cobra.newdream.net \
--to=sage@newdream.net \
--cc=abartlet@catalyst.net.nz \
--cc=ceph-devel@vger.kernel.org \
--cc=mbroz@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.