Open Stack

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.

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

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

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

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-identit
>>>>> 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-identity
>>>> -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
>