[openstack-dev] [Neutron][LBaaS]TLS API support for authentication

Stephen Balukoff sbalukoff at bluebox.net
Wed May 28 02:13:50 UTC 2014


Hi y'all!


On Fri, May 23, 2014 at 1:24 PM, Carlos Garza <carlos.garza at rackspace.com>wrote:

>     Right so are you advocating that the front end API never return a
> private key back to the user once regardless if the key was generated
> on the back end or sent in to the API from the user? We kind of are
> already are implying that they can refer to the key via a private
> key id.
>

I would advocate that if the user asks the front-end API for the private
key information (ie. "GET" request), what they get back is the key's
modulus and nothing else. This should work to verify whether a given key
matches a given cert, and doesn't break security requirements for those who
are never allowed to actually touch private key data. And if a user added
the key themselves through the front-end API, I think it's safe to assume
the responsibility for keeping a copy of the key they can access lies with
the user.

Having said this, of course anything which spins up virtual appliances, or
configures physical appliances is going to need access to the actual
private key. So any back-end API(s) will probably need to have different
behavior here.

One thing I do want to point out is that with the 'transient' nature of
back-end guests / virtual servers, it's probably going to be important to
store the private key data in something non-volatile, like barbican's
store. While it may be a good idea to add a feature that generates a
private key and certificate signing request via our API someday for certain
organizations' security requirements, one should never have the only store
for this private key be a single virtual server. This is also going to be
important if a certificate + key combination gets re-used in another
listener in some way, or when horizontal scaling features get added.

Thanks,
Stephen

-- 
Stephen Balukoff
Blue Box Group, LLC
(800)613-4305 x807
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140527/bfafc9fb/attachment.html>


More information about the OpenStack-dev mailing list