[openstack-dev] [nova][keystone] Message Queue Security

Bhandaru, Malini K malini.k.bhandaru at intel.com
Mon Apr 29 18:02:42 UTC 2013

Eric -- The keyserver/key-manager will be built to scale. Stay tuned to developments. Our messages will be tagged
With "[openstack-dev][barbican]"
When I attended your secure RPC design summit session, noted that it is yet another piece that
Can use the key manager, and cache public keys and certificates as necessary to reduce
Chatter with the key manager.

-----Original Message-----
From: Simo Sorce [mailto:simo at redhat.com] 
Sent: Friday, April 26, 2013 7:14 PM
To: OpenStack Development Mailing List
Subject: Re: [openstack-dev] [nova][keystone] Message Queue Security

On Fri, 2013-04-26 at 20:11 -0400, Eric Windisch wrote:
> I meant the keyserver software itself. Your keyserver needs to be a 
> custom built to purpose service. To scale that keyserver, you'll need 
> to run more of them. Maybe you can deploy some HTTP proxies for 
> caching. This is additional infrastructure for organizations to 
> support and organizations will only add as much as they can afford to.

I am currently planning to bake this stuff into keystone, but it could be a separate service.
In any case I am being careful in the design about making sure it is easy to deploy duplicate copies to allow scaling.

> A PKI-based solution could potentially allow a pluggable keysever 
> component that might be scaled in a variety of ways that may leverage 
> existing infrastructure.  DNS, Swift, etc…
> However, to play devil's advocate against myself, if the PKI solution 
> doesn't *also* use a custom built-to-purpose service as a keyserver, 
> it complicates the revocation story.

You cannot handle revocation at all, nor you can check the certificates are legit to start with. I don't think there is any chance to run a PKI based system without a Central Authority, or some sort of central repository.

> At least, perhaps, with PKI we do open the possibility of a pluggable 
> keyserver mechanism and changing the keyserver solution -- whereas the 
> shared-key solution will need to be much more baked-in and 
> tightly-coupled?

Not sure what this means honestly.

Simo Sorce * Red Hat, Inc * New York

OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org

More information about the OpenStack-dev mailing list