Open Stack

OK, starting to see how this works now. I'd be interested in how you guys do it.
Thanks for the explanation.

Cheers,
Sam


On 14/12/2012, at 5:08 AM, Joshua Harlow <harlowja at yahoo-inc.com> wrote:

> + The right openstack-dev, haha
> 
> On 12/13/12 10:06 AM, "Joshua Harlow" <harlowja at yahoo-inc.com> wrote:
> 
>> + Openstack-dev
>> 
>> On 12/13/12 10:05 AM, "Joshua Harlow" <harlowja at yahoo-inc.com> wrote:
>> 
>>> At some point a clear-text password will show up, but that doesn't
>>> require
>>> said password to always be in clear-text.
>>> 
>>> Think of a remote system that provides said passwords and authenticates
>>> the system asking for said password using some private/public key
>>> authentication that can be easily revoked (on machine comprise and such).
>>> Then u will get a closer view to why it'd be nice to have keys go through
>>> a API so that they can be gotten from other sources (to enable such a
>>> system to work). The plain-text case is an API, but it restricts it to
>>> the
>>> simplest one (only plain-text files), other companies (cough cough,
>>> yahoo)
>>> have different systems.
>>> 
>>> On 12/12/12 9:26 PM, "Sam Morrison" <sorrison at gmail.com> wrote:
>>> 
>>>> Hi Ken,
>>>> 
>>>> Yeah OK I agree it doesn't make it that much more complex as long as the
>>>> dependancy is packaged in the distos which it is.
>>>> 
>>>> I'm still a little confused though.
>>>> 
>>>> If nova needs a clear text password to be able to talk to the DB for
>>>> example then it's going to be needing to access this keyring somehow
>>>> without human interaction to obtain the password.
>>>> How does it do this? Sorry if I'm missing something obvious here.
>>>> 
>>>> Cheers,
>>>> Sam
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> On 13/12/2012, at 10:16 AM, Ken Thomas <krt at yahoo-inc.com> wrote:
>>>> 
>>>>> The short answer is that it gives you extra security... if you wish to
>>>>> use it.
>>>>> 
>>>>> If you're fine with relying on the file permission of nova.conf,
>>>>> glance.conf, etc. to keep any baddies from seeing the clear text
>>>>> passwords in there, then you're right, it doesn't give you anything.
>>>>> 
>>>>> If, on the other hand, you have a large security group that nearly
>>>>> faints when they see clear text passwords, no matter what the file
>>>>> permission are, this allows you to move your password into an encrypted
>>>>> store of your choosing.  Just specify a secure_source that implements
>>>>> KeyringBackend and you can be as secure as you wish.
>>>>> 
>>>>> The main point is that you don't have to use it and the default
>>>>> behavior (don't specify a 'secure_source') will be that things behave
>>>>> exactly as before.  The only real extra complexity is that we'd add an
>>>>> additional package (keyring) to the dependency list.
>>>>> 
>>>>> As I mentioned originally, there's already some optional keyring usage
>>>>> in keystone client. It seems like we could have *less* complexity if it
>>>>> were a hard dependency instead of having the code check if the import
>>>>> worked or not.
>>>>> 
>>>>> Ken
>>>>> 
>>>>> On 12/12/2012 2:46 PM, Sam Morrison wrote:
>>>>>> My question is what does this extra dependancy give us apart from
>>>>>> extra complexity?
>>>>>> 
>>>>>> I can't see any enhancement in security with this method?
>>>>>> 
>>>>>> Cheers,
>>>>>> Sam
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> On 13/12/2012, at 4:44 AM, Ken Thomas <krt at yahoo-inc.com> wrote:
>>>>>> 
>>>>>>> Greetings all!
>>>>>>> 
>>>>>>> I'm look into using keyring as a way to (optionally) remove clear
>>>>>>> text passwords from the various config files. (See
>>>>>>> https://blueprints.launchpad.net/oslo/+spec/pw-keyrings for details.)
>>>>>>> 
>>>>>>> One of the comments I got back is that I should have the oslo build
>>>>>>> dependency on keyring be optional until a consensus is reached that
>>>>>>> it's okay to add it.  I see that keystoneclient is already doing an
>>>>>>> "import keyring" and catching the exception if it's not there. I can
>>>>>>> certainly do something similar, but it seems like it would simplify
>>>>>>> things if we did just have keyring as a regular hard dependency. You
>>>>>>> don't have to use it, but it's there if you want it.
>>>>>>> 
>>>>>>> So, is this the proper forum to bring this up?
>>>>>>> 
>>>>>>> And if so, can we start the ball rolling to get a decision on
>>>>>>> getting
>>>>>>> that dependency approved?
>>>>>>> 
>>>>>>> Thanks,
>>>>>>> 
>>>>>>> Ken
>>>>>>> 
>>>>>>> _______________________________________________
>>>>>>> Mailing list: https://launchpad.net/~openstack
>>>>>>> Post to     : openstack at lists.launchpad.net
>>>>>>> Unsubscribe : https://launchpad.net/~openstack
>>>>>>> More help   : https://help.launchpad.net/ListHelp
>>>>> 
>>>> 
>>>> 
>>>> _______________________________________________
>>>> Mailing list: https://launchpad.net/~openstack
>>>> Post to     : openstack at lists.launchpad.net
>>>> Unsubscribe : https://launchpad.net/~openstack
>>>> More help   : https://help.launchpad.net/ListHelp
>>> 
>> 
>> 
>