Open Stack

Hi Simo,

I am lost.
 
Does Barbican is product came out of https://wiki.openstack.org/wiki/KeyManager BP?

If yes, then why it is deviating from the BP which says Key Manager will be separate service but not a part of Keystone.

If no, then why we are thinking about new Key manager (which seems to me a subset of above BP)? 


Arvind

-----Original Message-----
From: Simo Sorce [mailto:simo at redhat.com] 
Sent: Tuesday, July 02, 2013 8:57 AM
To: OpenStack Development Mailing List
Subject: Re: [openstack-dev] Move keypair management out of Nova and into Keystone?

On Tue, 2013-07-02 at 10:07 -0400, Jay Pipes wrote:
> On 07/02/2013 09:49 AM, Jarret Raim wrote:
> > I've spent some time thinking about how Barbican (Key Management) can help
> > in this workflow.
> >
> > We will have the ability to generate SSH keys (and a host of other key &
> > certificate types). This is backed by cryptographically sound code and
> > we've spent some time figuring out the entropy problem and HSM support. If
> > the keys are stored in Barbican, we'd get the audit / logging and other
> > functionality needed for compliance.
> 
> What does the above mean? What about Barbican is audited/logged that 
> isn't in Keystone and why wouldn't such auditing/logging be added to 
> Keystone if it were needed for compliance? I'm trying to figure out why 
> there is yet another OpenStack-related project for storing 
> keys/credentials when Keystone already exists.

Barbican is meant to store primarily private/simmetric keys in a way
that allows user to get access to them after proper keystone
integration. This material is particularly sensitive and it was felt
that we needed a specific service that would have a higher level of
scrutiny and security. This is better achieved if the tool does only one
thing with a smallest code footprint than if it is merged together with
unrelated code. Auditing of code is expensive (mostly in terms of
time/eyes), so keeping a specialized service for these keys makes sense.

>  > We also get federation which will
> > allow customers of public Clouds (or shared private Clouds) to maintain
> > custody of their own keys rather than storing them in the provider.
> 
> I don't understand. Users already have custody of their own keys. The 
> only thing that Keystone/Nova has is the public key fingerprint [1], not 
> the private key...

You acatually have the public key, not just the fingerprint, but indeed
I do not see why abrbican should be involved here.  apublic key does not
need the same level of protection of a private key or a symmetric
encryption key, so by storing this data in barbican we would only
needlessly expose barbican to more access patternsand more
logging/auditing volume than is needed. 

> > There seem to be a couple of ways to take advantage of this functionality.
> > If a key is specific to a user, then Keystone could store a URI to the key
> > in Barbican and Nova could request it on server creation. Alternatively,
> > the user could pass a URI to a key into Nova directly. If we want to move
> > to always enabling SSH key access only on boot, Nova could create a key
> > under the requesting tenant in Barbican and use it on server create.
> 
> OK, so the above would basically be a "driver" in Keystone parlance for 
> the credentials module, where Keystone would just store the key in 
> Barbican and retrieve said key.
> 
> At this point, though, what exactly is the point of Barbican over a 
> simple database or KVS driver?

Not much, and perhaps even worsen the situation as I hinted above, but I
think Jared assumed you were talking about generating/storing private
keys, and as you noted it is not the case.

> > Things get more interesting when we are talking about IPSec certificates
> > and the like. Barbican seems a more logical place to generate / store /
> > share these types of keys than Keystone.
> 
> Generate...perhaps. Store... I doubt it. Share...I think Keystone is the 
> most logical place to share credentials. After all, it's the 
> authentication/identity component in OpenStack.

Nope, if you need to store private keys that you need to routinely
retrieve and re-distribute then barbican is the right and only place.

> While encryption and key generation are interesting topics, they are 
> tangential to the fact that credentials are an attribute of the 
> identity/user, and that information is in Keystone.

If 'access credentials' remain buried (as in they cannot never be
retrieved) in Keystone (or whatever IdM service it bridges to) then it
is probably the right place as it performs authentication anyway and
needs direct access to these credentials internally in some cases.

But Keystone is not the right place to function as storage and retrieval
system for private keys that's barbican's turf.

So for the nova keypairs I think Keystone is the natural place, as that
information doesn't need strong protection, it's just public keys.
For private keys Keystone wouldn't do, and a URL redirection scheme as
proposed by Jarret makes a lot of sense in this case.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York


_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev