openstack team mailing list archive

[Joshua Harlow <harlowja@xxxxxxxxxxxxx>]

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