From: Milan Broz <mbroz@redhat.com>
To: Sage Weil <sage@newdream.net>,
Andrew Bartlett <abartlet@catalyst.net.nz>
Cc: ceph-devel@vger.kernel.org
Subject: Re: Interested in ceph OSD encryption and key management
Date: Thu, 18 Jun 2015 15:34:42 +0200 [thread overview]
Message-ID: <5582C8F2.2010604@redhat.com> (raw)
In-Reply-To: <alpine.DEB.2.00.1506162115350.16406@cobra.newdream.net>
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?
> 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).
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.
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.)
Milan
next prev parent reply other threads:[~2015-06-18 13:34 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 [this message]
2015-06-18 14:31 ` Sage Weil
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=5582C8F2.2010604@redhat.com \
--to=mbroz@redhat.com \
--cc=abartlet@catalyst.net.nz \
--cc=ceph-devel@vger.kernel.org \
--cc=sage@newdream.net \
/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.