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" <sorri...@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 <k...@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 <k...@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@lists.launchpad.net >>>> Unsubscribe : https://launchpad.net/~openstack >>>> More help : https://help.launchpad.net/ListHelp >> > > >_______________________________________________ >Mailing list: https://launchpad.net/~openstack >Post to : openstack@lists.launchpad.net >Unsubscribe : https://launchpad.net/~openstack >More help : https://help.launchpad.net/ListHelp _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp