Open Stack

On Mon, Oct 22, 2012 at 11:13:19AM -0400, Eric Windisch wrote:
> 
> 
> On Saturday, October 20, 2012 at 17:39 PM, Vipul Sabhaya wrote:
> 
> > Hi,
> >  
> > I'm a developer on the RedDwarf project.  I missed the session on Trusted
> > RPC Messaging at the summit, and we are hoping to use this when it's available.
> >  I had some implementation/scope questions that someone may be able to answer.  
> >  
> > 1.  Is encryption of the message also in scope? or is the plan to only sign at
> > this point?
>
> The scope is to have trust between components. Signing is necessary for that,
> but not encryption. Encryption will be a more substantial change to the
> messaging format and will more heavily depend on a key management solution.
> My thoughts are to do signing first, encryption later.

I have been working on designs for disk encryption in the libvirt driver for
Nova, and one of the key requirements for this work is to get both encryption
and signing of messages (to protect key material passed between services). So
from my POV I think we need to bite the bullet and go straight for a solution
that provides both signing & encryption. I also need to have quite fine grained
identity management - eg not simply per-host certs, but per-(host,service)
certs, so you can distinguish messages from a Nova 'compute' service vs the
'schedular' service vs the 'api' service.

Do you have any formal design document for what you are proposing for the RPC
layer security ?  I'm 1/2 way through writing up a design document for what I
was going to propose and should be able to share it towards the 2nd half of
next week. I'd like to make sure we collaborate on secure messaging to get a
solution that meets all our goals.

> > 2.  What is the solution around key management?
> 
> Generally, certificate management will look a lot like SSL certificate
> management. The pattern is well known. You generate a private key and a
> CSR on each host. You send the CSR to a CA for signing. You get a certificate
> back.  The main difference to public SSL is that you'll want to run your own
> CA.
> 
> Additionally, this will depend on a keyserver, like other session-less PKI
> systems such as PGP / GPG. The system will be pluggable so that various
> keyservers can be plumbed in. Some CA solutions include keyservers.
> 
> There are existing CA solutions that one can deploy, such as Dogtag, RHCA,
> EJBCA, SimpleCA, OpenCA, and NewPKI. This list is non-exhaustive.  There
> is almost as long a list of dedicated keyserver options. We don't need to
> reinvent the wheel. Distributions can choose one, or even build one, and
> we can give examples. (I haven't deeply evaluated all the above options…
> caveat emptor)
> 
> Overall, I see this as a place for vendors to step up and provide solutions.

I've not examined the options either, but I had thought that it may well
be desirable to have Keystone be the hub to provide the certificate
management interfaces. One of my desires is that RPC encryption + signing
be something that people are able to have enabled out of the box, with
every single OpenStack install, possibly even going as far as making it a
compulsory feature for all. Thus I'm somewhat wary of requiring that
people deploy a significant piece of external infrastructure as a
pre-requisite for OpenStack. By the same logic, it is important that
use of secure messaging should not be imposing any significant ongoing
administrative overhead. That said, it could well be pratical to have a
simple defautl cert manager built into keystone, which is then optionally
pluggable with 3rd party solutions if desired. All TBD of course.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|