Re: [openstack-dev] Move keypair management out of Nova and into Keystone?

[Jarret Raim]

On 7/2/13 12:43 PM, "Simo Sorce"  wrote:


>On Tue, 2013-07-02 at 16:55 +, Tiwari, Arvind wrote:
>> Hi Simo,
>> 
>> I am lost.
>>  
>> Does Barbican is product came out of
>>https://wiki.openstack.org/wiki/KeyManager BP?
>
>Yes Barbican is an implementation of this Blueprint afaik.

Barbican is based on the goals of this blueprint. We revised a lot of it,
but the goals are the same. The current documentation can be found here:

https://github.com/cloudkeep/barbican/wiki

https://github.com/cloudkeep/barbican


>
>> If yes, then why it is deviating from the BP which says Key Manager
>>will be separate service but not a part of Keystone.
>
>Sorry I don't follow, Barbican is separated from Keystone.

Correct. Barbican is a separate service. We use Keystone for auth
(obviously), but we have our own infrastructure.


Jarret


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

Re: [openstack-dev] Move keypair management out of Nova and into Keystone?

[Bryan D. Payne]

> If you do not trust keystone to give you the right information you have
> already lost as keystone is used (afaik) to check for authorization
> anyway.
>

This is true.


> Can you be a little bit more explicit on the threat model you have in
> mind and what guarantees Barbican would give you that would make it more
> suitable to store public key than Keystone ?


I'm concerned about malicious tampering with the keys.  If the keys are
then use for validating that a user is presenting the correct private key,
this could result in an instance compromise.  Yes, if someone tampers with
other data in keystone then it could result in a compromise as well.  This
is true.

As I think about this some more, I think the best way to frame it is that
-- for me -- key data and user / password data are two different classes
that may have different security requirements.  It is nice to not mix the
two, IMHO.  However, I can appreciate the simplicity that comes with just
not using Barbican and throwing everything in Keystone.

WIth this in mind, I do like the idea of having Keystone return a pointer
to the key location as URL.  This can be a ref back to a Keystone route.
 Or it can be a ref to a Barbican route.  This would be most flexible and
allow people to fullfil different security and auditing requirements.

-bryan
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Move keypair management out of Nova and into Keystone?

[Ryan Lane]

On Tue, Jul 2, 2013 at 8:12 AM, Bryan D. Payne  wrote:

>
>  > 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.
>>
>
> I believe you're confusing a couple of points here.  In this case, for
> public keys, what matters is integrity.  For the other cases that you
> mentioned, both integrity and confidentiality matter.  I believe that given
> the high integrity requirements that it *does* make sense to store these in
> a more protected location.
>
> +1 for using Barbican
>
>
This would make Barbican a required service for running Nova. Keystone is
already required and it has the necessary functionality.

- Ryan
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Move keypair management out of Nova and into Keystone?

[Jarret Raim]

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

Re: [openstack-dev] Move keypair management out of Nova and into Keystone?

[Simo Sorce]

On Tue, 2013-07-02 at 16:55 +, Tiwari, Arvind wrote:
> Hi Simo,
> 
> I am lost.
>  
> Does Barbican is product came out of 
> https://wiki.openstack.org/wiki/KeyManager BP?

Yes Barbican is an implementation of this Blueprint afaik.

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

Sorry I don't follow, Barbican is separated from Keystone.

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

New ?

Simo.

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


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

Re: [openstack-dev] Move keypair management out of Nova and into Keystone?

[Simo Sorce]

On Tue, 2013-07-02 at 08:12 -0700, Bryan D. Payne wrote:
> 
> > 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.
> 
> 
> I believe you're confusing a couple of points here.  In this case, for
> public keys, what matters is integrity.  For the other cases that you
> mentioned, both integrity and confidentiality matter.  I believe that
> given the high integrity requirements that it *does* make sense to
> store these in a more protected location.
> 
> 
> +1 for using Barbican
> 
If you do not trust keystone to give you the right information you have
already lost as keystone is used (afaik) to check for authorization
anyway.

Can you be a little bit more explicit on the threat model you have in
mind and what guarantees Barbican would give you that would make it more
suitable to store public key than Keystone ?

Simo.

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


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

Re: [openstack-dev] Move keypair management out of Nova and into Keystone?

[Tiwari, Arvind]

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:s...@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

Re: [openstack-dev] Move keypair management out of Nova and into Keystone?

[Bryan D. Payne]

>  +1 for using Barbican
>>
>
> Simo just got finished saying Barbican was *not* the correct place to put
> this information...


Understood.  I'm disagreeing with Simo.  And I'm agreeing with Jarret Raim.

-bryan
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Move keypair management out of Nova and into Keystone?

[Jay Pipes]

On 07/02/2013 11:12 AM, Bryan D. Payne wrote:


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


I believe you're confusing a couple of points here.  In this case, for
public keys, what matters is integrity.  For the other cases that you
mentioned, both integrity and confidentiality matter.  I believe that
given the high integrity requirements that it *does* make sense to store
these in a more protected location.

+1 for using Barbican

-bryan


Simo just got finished saying Barbican was *not* the correct place to 
put this information...


-jay




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

Re: [openstack-dev] Move keypair management out of Nova and into Keystone?

[Bryan D. Payne]

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

I believe you're confusing a couple of points here.  In this case, for
public keys, what matters is integrity.  For the other cases that you
mentioned, both integrity and confidentiality matter.  I believe that given
the high integrity requirements that it *does* make sense to store these in
a more protected location.

+1 for using Barbican

-bryan
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Move keypair management out of Nova and into Keystone?

[Jay Pipes]

On 07/02/2013 10:56 AM, Simo Sorce wrote:


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.


No disagreement at all from me on this one! :)


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.


++

-jay


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

Re: [openstack-dev] Move keypair management out of Nova and into Keystone?

[Simo Sorce]

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@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Move keypair management out of Nova and into Keystone?

[Dolph Mathews]

On Monday, July 1, 2013, 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-identity-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.


+1; I'd like to know what the gap is from Identity API v3's /credentials to
nova key pair API, if any. The credential API was intended to avoid making
too many assumptions about how it would be used, so hopefully it can be
adopted as it is for EC2 creds today.


>
> 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.
>
> >
> >
> > 2013/7/1 Thierry Carrez >:
> > > Russell Bryant wrote:
> > >> On 07/01/2013 01:10 PM, Jay Pipes wrote:
> > >>> On 07/01/2013 12:23 PM, Mauro S M Rodrigues wrote:
> >  +1.. make sense to me, I always thought that was weird hehe
> >  Say the word and we will remove it from v3.
> > >>>
> > >>> Well, it's not weird, per-se... I mean I understand why it is the
> way it
> > >>> is. Nova, of course, preceded Keystone.
> > >>>
> > >>> But, it sounds like this would be something to put on the Icehouse
> > >>> horizon? Can the Nova and Keystone PTLs comment if there is interest
> in
> > >>> this?
> > >>
> > >> There is interest from me.  Dolph?
> > >
> > > Dolph is not around this week, so the answer may take a while :)
> > >
> > > --
> > > Thierry Carrez (ttx)
> > >
> > > ___
> > > OpenStack-dev mailing list
> > > OpenStack-dev@lists.openstack.org 
> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> > ___
> > OpenStack-dev mailing list
> > OpenStack-dev@lists.openstack.org 
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>


-- 

-Dolph
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Move keypair management out of Nova and into Keystone?

[Jay Pipes]

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"  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@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/open

Re: [openstack-dev] Move keypair management out of Nova and into Keystone?

[Jarret Raim]

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

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

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"  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@lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

Re: [openstack-dev] Move keypair management out of Nova and into Keystone?

[Jay Pipes]

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-identity-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@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Move keypair management out of Nova and into Keystone?

[Simo Sorce]

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

Simo.

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


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

Re: [openstack-dev] Move keypair management out of Nova and into Keystone?

[Day, Phil]

> -Original Message-
> From: Jay Pipes [mailto:jaypi...@gmail.com]
> Sent: 02 July 2013 02:04
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] Move keypair management out of Nova and into
> Keystone?
> 
> 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-identity-
> 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?
> 
> Best,
> -jay
> 

Yep - following the pattern set by things like the floating IP and SecGroups 
APIs as these moved to Quantum would defiantly be the way to go.

Beyond just the Nova API shim we'd need to change the logic in the server 
creation to get the key value from Keystone rather than the Nova DB.
There is a KeypairAPI in compute/api.py but not everything is abstracted to use 
it at the moment.   If we tidy that up then that would provide the redirection 
point to Keystone. 
  

It would also be really good if there was a migration tool developed at the 
same time to migrate existing keys from Nova to Quantum.

Phil

> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] Move keypair management out of Nova and into Keystone?

[Jay Pipes]

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


Best,
-jay


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

Re: [openstack-dev] Move keypair management out of Nova and into Keystone?

[Nachi Ueno]

Hi Jamie

Thanks for sharing Keystone's v3 credential api.
( I didn't know this..)
Neutron VPN can use this api ! :)

Best
Nachi


2013/7/1 Jamie Lennox :
> 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-identity-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.
>
>>
>>
>> 2013/7/1 Thierry Carrez :
>> > Russell Bryant wrote:
>> >> On 07/01/2013 01:10 PM, Jay Pipes wrote:
>> >>> On 07/01/2013 12:23 PM, Mauro S M Rodrigues wrote:
>>  +1.. make sense to me, I always thought that was weird hehe
>>  Say the word and we will remove it from v3.
>> >>>
>> >>> Well, it's not weird, per-se... I mean I understand why it is the way it
>> >>> is. Nova, of course, preceded Keystone.
>> >>>
>> >>> But, it sounds like this would be something to put on the Icehouse
>> >>> horizon? Can the Nova and Keystone PTLs comment if there is interest in
>> >>> this?
>> >>
>> >> There is interest from me.  Dolph?
>> >
>> > Dolph is not around this week, so the answer may take a while :)
>> >
>> > --
>> > Thierry Carrez (ttx)
>> >
>> > ___
>> > OpenStack-dev mailing list
>> > OpenStack-dev@lists.openstack.org
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] Move keypair management out of Nova and into Keystone?

[Jamie Lennox]

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

> 
> 
> 2013/7/1 Thierry Carrez :
> > Russell Bryant wrote:
> >> On 07/01/2013 01:10 PM, Jay Pipes wrote:
> >>> On 07/01/2013 12:23 PM, Mauro S M Rodrigues wrote:
>  +1.. make sense to me, I always thought that was weird hehe
>  Say the word and we will remove it from v3.
> >>>
> >>> Well, it's not weird, per-se... I mean I understand why it is the way it
> >>> is. Nova, of course, preceded Keystone.
> >>>
> >>> But, it sounds like this would be something to put on the Icehouse
> >>> horizon? Can the Nova and Keystone PTLs comment if there is interest in
> >>> this?
> >>
> >> There is interest from me.  Dolph?
> >
> > Dolph is not around this week, so the answer may take a while :)
> >
> > --
> > Thierry Carrez (ttx)
> >
> > ___
> > OpenStack-dev mailing list
> > OpenStack-dev@lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




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

Re: [openstack-dev] Move keypair management out of Nova and into Keystone?

[Nachi Ueno]

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



2013/7/1 Thierry Carrez :
> Russell Bryant wrote:
>> On 07/01/2013 01:10 PM, Jay Pipes wrote:
>>> On 07/01/2013 12:23 PM, Mauro S M Rodrigues wrote:
 +1.. make sense to me, I always thought that was weird hehe
 Say the word and we will remove it from v3.
>>>
>>> Well, it's not weird, per-se... I mean I understand why it is the way it
>>> is. Nova, of course, preceded Keystone.
>>>
>>> But, it sounds like this would be something to put on the Icehouse
>>> horizon? Can the Nova and Keystone PTLs comment if there is interest in
>>> this?
>>
>> There is interest from me.  Dolph?
>
> Dolph is not around this week, so the answer may take a while :)
>
> --
> Thierry Carrez (ttx)
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] Move keypair management out of Nova and into Keystone?

[Thierry Carrez]

Russell Bryant wrote:
> On 07/01/2013 01:10 PM, Jay Pipes wrote:
>> On 07/01/2013 12:23 PM, Mauro S M Rodrigues wrote:
>>> +1.. make sense to me, I always thought that was weird hehe
>>> Say the word and we will remove it from v3.
>>
>> Well, it's not weird, per-se... I mean I understand why it is the way it
>> is. Nova, of course, preceded Keystone.
>>
>> But, it sounds like this would be something to put on the Icehouse
>> horizon? Can the Nova and Keystone PTLs comment if there is interest in
>> this?
> 
> There is interest from me.  Dolph?

Dolph is not around this week, so the answer may take a while :)

-- 
Thierry Carrez (ttx)

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

Re: [openstack-dev] Move keypair management out of Nova and into Keystone?

[Russell Bryant]

On 07/01/2013 01:10 PM, Jay Pipes wrote:
> On 07/01/2013 12:23 PM, Mauro S M Rodrigues wrote:
>> +1.. make sense to me, I always thought that was weird hehe
>> Say the word and we will remove it from v3.
> 
> Well, it's not weird, per-se... I mean I understand why it is the way it
> is. Nova, of course, preceded Keystone.
> 
> But, it sounds like this would be something to put on the Icehouse
> horizon? Can the Nova and Keystone PTLs comment if there is interest in
> this?

There is interest from me.  Dolph?

-- 
Russell Bryant

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

Re: [openstack-dev] Move keypair management out of Nova and into Keystone?

[Mauro S M Rodrigues]

yes, of course...

On 07/01/2013 02:07 PM, Joe Gordon wrote:


We should not remove it from the v3 API until we know this will be 
supported by keystone in Havana.


best,
Joe

sent on the go

On Jul 1, 2013 6:25 PM, "Mauro S M Rodrigues" 
mailto:maur...@linux.vnet.ibm.com>> wrote:


+1.. make sense to me, I always thought that was weird hehe
Say the word and we will remove it from v3.

On 07/01/2013 01:02 PM, Russell Bryant wrote:

On 07/01/2013 11:47 AM, Jay Pipes wrote:

Recently a colleague asked me whether their key pair from
one of our
deployment zones would be usable in another deployment
zone. His
identity credentials are shared between the two zones (we
use a shared
identity database) and was wondering if the key pairs were
also shared.

I responded that no, they were not, because Nova, not
Keystone, manages
key pairs. But that got me thinking is it time to
change this?

Key pairs really are an element of
identity/authentication, and not
specific to OpenStack Compute. Has there been any talk of
moving the key
pair management API out of Nova and into Keystone?

I haven't heard any talk about it, but it does seem to make sense.



___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



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


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

Re: [openstack-dev] Move keypair management out of Nova and into Keystone?

[Jay Pipes]

On 07/01/2013 12:23 PM, Mauro S M Rodrigues wrote:

+1.. make sense to me, I always thought that was weird hehe
Say the word and we will remove it from v3.


Well, it's not weird, per-se... I mean I understand why it is the way it 
is. Nova, of course, preceded Keystone.


But, it sounds like this would be something to put on the Icehouse 
horizon? Can the Nova and Keystone PTLs comment if there is interest in 
this?


Thanks!
-jay


On 07/01/2013 01:02 PM, Russell Bryant wrote:

On 07/01/2013 11:47 AM, Jay Pipes wrote:

Recently a colleague asked me whether their key pair from one of our
deployment zones would be usable in another deployment zone. His
identity credentials are shared between the two zones (we use a shared
identity database) and was wondering if the key pairs were also shared.

I responded that no, they were not, because Nova, not Keystone, manages
key pairs. But that got me thinking is it time to change this?

Key pairs really are an element of identity/authentication, and not
specific to OpenStack Compute. Has there been any talk of moving the key
pair management API out of Nova and into Keystone?

I haven't heard any talk about it, but it does seem to make sense.




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



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

Re: [openstack-dev] Move keypair management out of Nova and into Keystone?

[Joe Gordon]

We should not remove it from the v3 API until we know this will be
supported by keystone in Havana.

best,
Joe

sent on the go
On Jul 1, 2013 6:25 PM, "Mauro S M Rodrigues" 
wrote:

> +1.. make sense to me, I always thought that was weird hehe
> Say the word and we will remove it from v3.
>
> On 07/01/2013 01:02 PM, Russell Bryant wrote:
>
>> On 07/01/2013 11:47 AM, Jay Pipes wrote:
>>
>>> Recently a colleague asked me whether their key pair from one of our
>>> deployment zones would be usable in another deployment zone. His
>>> identity credentials are shared between the two zones (we use a shared
>>> identity database) and was wondering if the key pairs were also shared.
>>>
>>> I responded that no, they were not, because Nova, not Keystone, manages
>>> key pairs. But that got me thinking is it time to change this?
>>>
>>> Key pairs really are an element of identity/authentication, and not
>>> specific to OpenStack Compute. Has there been any talk of moving the key
>>> pair management API out of Nova and into Keystone?
>>>
>> I haven't heard any talk about it, but it does seem to make sense.
>>
>>
>
> __**_
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.**org 
> http://lists.openstack.org/**cgi-bin/mailman/listinfo/**openstack-dev
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Move keypair management out of Nova and into Keystone?

[Mauro S M Rodrigues]

+1.. make sense to me, I always thought that was weird hehe
Say the word and we will remove it from v3.

On 07/01/2013 01:02 PM, Russell Bryant wrote:

On 07/01/2013 11:47 AM, Jay Pipes wrote:

Recently a colleague asked me whether their key pair from one of our
deployment zones would be usable in another deployment zone. His
identity credentials are shared between the two zones (we use a shared
identity database) and was wondering if the key pairs were also shared.

I responded that no, they were not, because Nova, not Keystone, manages
key pairs. But that got me thinking is it time to change this?

Key pairs really are an element of identity/authentication, and not
specific to OpenStack Compute. Has there been any talk of moving the key
pair management API out of Nova and into Keystone?

I haven't heard any talk about it, but it does seem to make sense.




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

Re: [openstack-dev] Move keypair management out of Nova and into Keystone?

[Monty Taylor]

On 07/01/2013 09:02 AM, Russell Bryant wrote:
> On 07/01/2013 11:47 AM, Jay Pipes wrote:
>> Recently a colleague asked me whether their key pair from one of our
>> deployment zones would be usable in another deployment zone. His
>> identity credentials are shared between the two zones (we use a shared
>> identity database) and was wondering if the key pairs were also shared.
>>
>> I responded that no, they were not, because Nova, not Keystone, manages
>> key pairs. But that got me thinking is it time to change this?
>>
>> Key pairs really are an element of identity/authentication, and not
>> specific to OpenStack Compute. Has there been any talk of moving the key
>> pair management API out of Nova and into Keystone?
> 
> I haven't heard any talk about it, but it does seem to make sense.

I agree. As a person who regularly uses multiple zones of several
clouds, needing to upload my keypair to each of them is, well, weird.

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

Re: [openstack-dev] Move keypair management out of Nova and into Keystone?

[Russell Bryant]

On 07/01/2013 11:47 AM, Jay Pipes wrote:
> Recently a colleague asked me whether their key pair from one of our
> deployment zones would be usable in another deployment zone. His
> identity credentials are shared between the two zones (we use a shared
> identity database) and was wondering if the key pairs were also shared.
> 
> I responded that no, they were not, because Nova, not Keystone, manages
> key pairs. But that got me thinking is it time to change this?
> 
> Key pairs really are an element of identity/authentication, and not
> specific to OpenStack Compute. Has there been any talk of moving the key
> pair management API out of Nova and into Keystone?

I haven't heard any talk about it, but it does seem to make sense.

-- 
Russell Bryant

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

[openstack-dev] Move keypair management out of Nova and into Keystone?

[Jay Pipes]

Recently a colleague asked me whether their key pair from one of our 
deployment zones would be usable in another deployment zone. His 
identity credentials are shared between the two zones (we use a shared 
identity database) and was wondering if the key pairs were also shared.


I responded that no, they were not, because Nova, not Keystone, manages 
key pairs. But that got me thinking is it time to change this?


Key pairs really are an element of identity/authentication, and not 
specific to OpenStack Compute. Has there been any talk of moving the key 
pair management API out of Nova and into Keystone?


Thanks!
-jay

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