+ The right openstack-dev, haha On 12/13/12 10:06 AM, "Joshua Harlow" <[email protected]> wrote:
>+ Openstack-dev > >On 12/13/12 10:05 AM, "Joshua Harlow" <[email protected]> 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" <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 : [email protected] >>>>>> Unsubscribe : https://launchpad.net/~openstack >>>>>> More help : https://help.launchpad.net/ListHelp >>>> >>> >>> >>>_______________________________________________ >>>Mailing list: https://launchpad.net/~openstack >>>Post to : [email protected] >>>Unsubscribe : https://launchpad.net/~openstack >>>More help : https://help.launchpad.net/ListHelp >> > > _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : [email protected] Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
