+ Openstack-dev On 12/13/12 10:05 AM, "Joshua Harlow" <harlo...@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" <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