openstack team mailing list archive

[Joshua Harlow <harlowja@xxxxxxxxxxxxx>]

+ The right openstack-dev, haha

On 12/13/12 10:06 AM, "Joshua Harlow" <harlowja@xxxxxxxxxxxxx> wrote:

>+ Openstack-dev
>
>On 12/13/12 10:05 AM, "Joshua Harlow" <harlowja@xxxxxxxxxxxxx> 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@xxxxxxxxx> 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@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxx
>>>>>> Unsubscribe : https://launchpad.net/~openstack
>>>>>> More help   : https://help.launchpad.net/ListHelp
>>>> 
>>>
>>>
>>>_______________________________________________
>>>Mailing list: https://launchpad.net/~openstack
>>>Post to     : openstack@xxxxxxxxxxxxxxxxxxx
>>>Unsubscribe : https://launchpad.net/~openstack
>>>More help   : https://help.launchpad.net/ListHelp
>>
>
>