openstack team mailing list archive

[Joshua Harlow <harlowja@xxxxxxxxxxxxx>]

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