Open Stack

Wrote this answer this morning, but Simo beat me to it. Answer below sent
for posterity.



TL;DR:

Jay - it seems like we are on the same page. Barbican can be helpful for
generation and storage (if needed) of various types of keying material.
However, if your use case is better served by storing the keys yourself,
than that seems fine.



On 7/2/13 9:07 AM, "Jay Pipes" <jaypipes at gmail.com> 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 has wider scope that Keystone. Keystone is the source for auth
and will store the keys that are associated for a particular user.
However, there are many reasons why keystone might not want to generate or
store keys. These include the various compliance regimes - almost all of
which have some requirements around key management (and identity). One of
Barbican's main goals is to provide the logging, auditing and reporting
needed for customers to meet their compliance obligations. Additionally,
high volume key creation can be tricky from a entropy point of view. We
will offer plugins that allow for the use of various entropy sources
(including the Intel chip stuff when it comes out) as well as support for
using a full HSM for key generation.

None of this means that Keystone couldn't be the API that other services
use to get their public SSH keys. It just means that Keystone might want
to use Barbican for key creation / storage. If we think the SSH pub key is
narrow enough use case, I don't have a problem with Keystone just storing
it.


> > 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...

This is true for SSH key access to nova. There will be other use cases
where we might want full certificates or some other keying material tied
to a user. 

>> 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?

>From Keystone's point of view, that's probably true. You can just use us a
dumb store if that makes the most sense for the use case.

For something like public SSH keys only, there is probably nothing wrong
with any type of storage (though there might be some requirements for key
auditing & rotation that need to be met). However, Barbican offers several
benefits over an internally maintained key storage service.

First, a single secure key storage service is better than each product
storing their own. This doesn't matter as much for Keystone as it is
already going to have to be secure, etc. but it does matter for all the
other Barbican customers.

Second, Barbican will always offer a free an open source implementation.
This allows any customer access to high quality, security crypto without
having to go to a vendor.

Third, Barbican will support hardware security modules, the Intel TPM and
rand stuff and other solutions for better quality / more secure crypto
products.

Fourth, Barbican is a simple ReST API that is open and doesn't require
custom code for a particular provider.

There is lots more, but you get the idea.

>> 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.
>
>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.

You may be right. There is nothing in Barbican that forces any particular
usage style. If Keystone wants to store the key and it makes sense for you
(as it may for the various types of auth crypto), then cool. Barbican will
provide the set of functionality that can be leveraged in this space and
each system can decide how best to use what is provided.

If there are use cases that people would see us participating in, I would
like to hear about them. We're happy to build features if systems need
them.


Thanks,
Jarret




>
>Best,
>-jay
>
>[1] 
>https://github.com/openstack/nova/blob/master/nova/db/sqlalchemy/models.py
>#L611
>
>> I'm open to other options - we are going to build this type of
>> functionality and I'm interested in how people would like to use it.
>>
>>
>>
>>
>> Jarret
>>
>>
>>
>> On 7/2/13 7:46 AM, "Jay Pipes" <jaypipes at gmail.com> wrote:
>>
>>> On 07/02/2013 08:26 AM, Simo Sorce wrote:
>>>> On Mon, 2013-07-01 at 21:03 -0400, Jay Pipes wrote:
>>>>> On 07/01/2013 07:49 PM, Jamie Lennox wrote:
>>>>>> On Mon, 2013-07-01 at 14:09 -0700, Nachi Ueno wrote:
>>>>>>> Hi folks
>>>>>>>
>>>>>>> I'm interested in it too.
>>>>>>> I'm working on VPN support for Neutron.
>>>>>>> Public key authentication is one of feature milestone in the IPsec
>>>>>>> implementation.
>>>>>>> But I believe key-pair management api and the implementation will
>>>>>>>be
>>>>>>> quite similar in Key for IPsec and Nova.
>>>>>>>
>>>>>>> so I'm +1 for moving key management for Keystone.
>>>>>>>
>>>>>>> Best
>>>>>>> Nachi
>>>>>>
>>>>>> I don't know how nova's keypair management works but i assume we are
>>>>>> talking about keys for ssh-ing into new virtual machines rather than
>>>>>> keys for authentication against nova.
>>>>>>
>>>>>> Keystone's v3 api has credentials storage (see
>>>>>>
>>>>>> 
>>>>>>https://github.com/openstack/identity-api/blob/master/openstack-ident
>>>>>>it
>>>>>> y-api/src/markdown/identity-api-v3.md ), is this sufficient on
>>>>>>behalf
>>>>>> of keystone? There is some support in the current master of
>>>>>> keystoneclient for working with these credentials.
>>>>>>
>>>>>> Otherwise would the upcoming barbican be a more appropriate place?
>>>>>>
>>>>>> If i've got this wrong and we are using these keys to actually
>>>>>> authenticate against nova then if someone can point me to the code
>>>>>> i'll
>>>>>> see how hard it is to transfer to keystone.
>>>>>
>>>>> Actually, no, I think you have it right (though the correct link is
>>>>>
>>>>> 
>>>>>https://github.com/openstack/identity-api/blob/master/openstack-identi
>>>>>ty
>>>>> -api/v3/src/markdown/identity-api-v3.md)
>>>>>
>>>>> I think the main work, though, has to be in removing/replacing the
>>>>>Nova
>>>>> API /keypairs stuff with calls to Keystone's v3/credentials API.
>>>>>
>>>>> Would the appropriate way to do this be to add an API shim into
>>>>>Nova's
>>>>> API that simply calls out to the Keystone v3/credentials API IFF
>>>>> Keystone's v3 API is enabled in the deployment? Then, deprecate the
>>>>>old
>>>>> code and when Keystone v2 API is sunsetted, then remove the old Nova
>>>>> keypairs API codepaths?
>>>>
>>>> I guess you also need to handle a migration of the data from one store
>>>> to the other ?
>>>> Or are these data migrations left as an exercise to the admins ?
>>>
>>> No, you are correct, a migration script should be included as part of
>>> the code.
>>>
>>> Best,
>>> -jay
>>>
>>>
>>> _______________________________________________
>>> OpenStack-dev mailing list
>>> OpenStack-dev at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
>_______________________________________________
>OpenStack-dev mailing list
>OpenStack-dev at lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev