Open Stack

On 12/10/2012 09:00 PM, Dan Prince wrote:
>
> ----- Original Message -----
>> From: "Adam Young" <ayoung at redhat.com>
>> To: openstack-dev at lists.openstack.org
>> Sent: Monday, December 10, 2012 11:56:28 AM
>> Subject: Re: [openstack-dev] default keyring use to False?
>>
>> On 12/10/2012 11:29 AM, Adam Young wrote:
>>> Stop.
>>>
>>> Collaborate and listen.
>>>
>>> Think very hard about which is more secure, caching or not-caching?
>>> You might be surprised.
>>>
>>>
>>> With the no-cache option, you end up caching the User Id and
>>> Password,
>>> either in an environment variable, your scripts, or something
>>>
>>> with the caching option, you cache the tokens
>>>
>>> This will cut down on the load on Keystone
>>> This will also be more secure.
>>>
>>> Lets find a way to fix the caching.  Lets not give in to the
>>> "security
>>> enhancements are annoying, lets disable them" reaction.
>> Having said that, I am totally OK with Dan's suggestions about how
>> not
>> to go ahead an break everything for development.  I'm talking long
>> term
>> view when I say we want caching by default.
> Thanks Adam.
>
> One finer point would be that my changes weren't just motivated by development... but by actually trying to use the new keystoneclient changes via real services (running as daemons from packages). I'm not sure it was intended but with these recent changes it appears python-keyring was being used by default *any* time keystoneclient was use... even as a library. (see this change https://review.openstack.org/#/c/17630/1/keystoneclient/client.py)
>
> My understanding was that python-keyring was for command line utilities only... and as such we should probably restrict its usage to the CLI right? I mean services can cache their own tokens already right... because they should just continue to run.
Well, maybe.  I can see an argument that Horizon should do its own 
caching, and the Keyring would get in the way there.  For something that 
is more work-flowy and using multiple processes to get something done, 
CLI wise or just library wise, I think Keyring is the right tool

The real question is how do we make Keyring work for completely 
automated deploys, the kind of thing that we would use a Kerberos Keytab 
for in Enterprise systems?  If we need to keep a cleartext password 
around anyway, we are kinda hosed.

It seems like the right solution would be to use either Kerberos or X509 
Authentication to get the initial token.  Ideally, Keyring would be set 
up to store the token in one of the exisitng stores (like an NSS 
Database) so we get a secure cache.



>
> Dan
>
>>>
>>> On 12/07/2012 02:07 PM, Dan Prince wrote:
>>>> Okay. Seems like there is some consensus on this so here are some
>>>> of
>>>> the relevant reviews:
>>>>
>>>> For novaclient (maintains backwards compat for the old --no-cache
>>>> args):
>>>>
>>>>    https://review.openstack.org/#/c/17692/ (Adds --os-cache to
>>>>    replace
>>>> old --no-cache.)
>>>>
>>>> For keystoneclient it just switches things over to use --os-cache.
>>>> This seems reasonable since keystoneclient was just updated with
>>>> these changes this week and we haven't tagged a release yet (that
>>>> I
>>>> know if):
>>>>
>>>>    https://review.openstack.org/#/c/17634/ (Rename --no_cache to
>>>> --os_cache.)
>>>>    https://review.openstack.org/#/c/17630/ (Make use_keyring False
>>>>    by
>>>> default.)
>>>>
>>>> Dan
>>>>
>>>> ----- Original Message -----
>>>>> From: "Joshua Harlow" <harlowja at yahoo-inc.com>
>>>>> To: "OpenStack Development Mailing List"
>>>>> <openstack-dev at lists.openstack.org>, "Dan Prince"
>>>>> <dprince at redhat.com>
>>>>> Sent: Friday, December 7, 2012 1:37:14 PM
>>>>> Subject: Re: [openstack-dev] default keyring use to False?
>>>>>
>>>>> Please do :-)
>>>>>
>>>>> +1
>>>>>
>>>>> On 12/6/12 7:36 PM, "Dan Prince" <dprince at redhat.com> wrote:
>>>>>
>>>>>> What are thoughts on disabling keyring use in our clients by
>>>>>> default?
>>>>>>
>>>>>> Some background:
>>>>>>
>>>>>> If you have python-keyring installed and try to use the most
>>>>>> recent
>>>>>> versions of novaclient and keystoneclient you'll end up with a
>>>>>> prompt
>>>>>> like this:
>>>>>>
>>>>>>    Please set a password for your new keyring
>>>>>>    Warning: Password input may be echoed.
>>>>>>    Password (again):
>>>>>>
>>>>>> To work around this many of us set --no-cache or even export an
>>>>>> environment variable OS_NO_CACHE. It seems like most people are
>>>>>> doing
>>>>>> this by default... so why not cut our losses here and change our
>>>>>> keyring
>>>>>> settings to be disabled by default.
>>>>>>
>>>>>> Now that this is included in keystoneclient this also effects
>>>>>> other
>>>>>> clients (which make use of it for auth) as well. I hit this
>>>>>> today
>>>>>> with
>>>>>> glanceclient... and it would presumably effect swiftclient as
>>>>>> well.
>>>>>>
>>>>>> To avoid the double negative perhaps changing the option to be
>>>>>> called
>>>>>> --os-cache (which would be defaulting to False) would make sense
>>>>>> as
>>>>>> well?
>>>>>> We could call the environment variable OS_CACHE as well.
>>>>>>
>>>>>> Dan
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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
>>
>> _______________________________________________
>> 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