Re: [Openstack] New build dependency on keyring
Hey Sam, Keyring is already in the distros? So I can go ahead and add it as a hard dependency to the build when I get this in? About your question,,, The basic idea is that you can define config keys a 'secure', and *if* you provide a 'secure_source', then cfg.py will use *your* code to get the value for that key. (See the blueprint mentioned in my original message for details.) That means that your nova.conf can have something like this: sql_connection = mysql://nova:$nova_db_password@dbhost:3306/nova You would then have a plugin that defines nova_db_password as 'secure' and your 'secure_source' code can do whatever you wish to return the password. It could pull it from some other clear text source (which would be kind of silly; we're trying to get away form that sort of thing) or it could extract and decrypt it from someplace else. Yes, using keyring's CryptedFileKeyring as your secure_source wouldn't be a good idea since it does need human interaction to get a password. The good news is that there are other ways to get and decrypt passwords... For example, we've got a proprietary secure password package that we use throughout our company and we're planning on having a thin layer that implements KeyringBackend and talks to that code. It makes our security folks happy because it moves the clear text passwords out of nova.conf, etc., but will still allow nova to access to passwords to set up things like db connections. I'm afraid I can't go into any details about how it does this without human intervention, because (1) I personally don't know the details, and (2) if I did, our security team would have to shoot me. ;-) The whole point of this is to provide the flexibility to choose to move your passwords elsewhere if you wish. If you do nothing, then it behaves exactly as to does today. Hope that helps! Ken On 12/12/2012 9:26 PM, Sam Morrison 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
[Openstack] New build dependency on keyring
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
Re: [Openstack] New build dependency on keyring
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
[Openstack] keystone folsom-backport timetable?
Hey all, Some keystone bugs tagged with ' folsom-backport ' were recently merged to master. Is there an ETA of when that backport will actually happen? And which branch/tag it'll be? 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
Re: [Openstack] keystone folsom-backport timetable?
Thanks! Ken On 10/25/2012 3:04 PM, heckj wrote: Hey Ken, Anyone can propose a backport at any time - I pestered Mark and he was kind enough to refer me to: * http://wiki.openstack.org/StableBranch#Proposing_Fixes and notes from the summit session around just this * https://etherpad.openstack.org/process-stable-branch I took a few minutes and ran through the two bugs slated for backports and proposed the reviews just now. Both merged cleanly, so I don't expect any significant issue - the stable/maint team will also review, and they'll be backported. https://review.openstack.org/14857 https://review.openstack.org/14858 - joe On Oct 25, 2012, at 9:42 AM, Ken Thomas k...@yahoo-inc.com mailto:k...@yahoo-inc.com wrote: Some keystone bugs tagged with ' folsom-backport ' were recently merged to master. Is there an ETA of when that backport will actually happen? And which branch/tag it'll be? Thanks, Ken ___ Mailing list: https://launchpad.net/~openstack https://launchpad.net/%7Eopenstack Post to : openstack@lists.launchpad.net mailto:openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack https://launchpad.net/%7Eopenstack 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
[Openstack] Keystone-dev question
Greetings all, I'm working on a keystone bug (to get my feet wetter) and I have a couple of questions. Could someone please take a look at comment #2 in https://bugs.launchpad.net/python-keystoneclient/+bug/1031245 (Get a User by Name) and let me know what y'all think? 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
Re: [Openstack] UnifiedCLI suggestion
The code checks that it's has a tty before it prompts. Automatic scripts should work just as before using the env variable or command line option. If they aren't present and there's no tty, then they'll error out exactly as they did before. Ken On 7/16/12 2:00 PM, Adam Young wrote: On 06/28/2012 11:54 AM, Dean Troyer wrote: On Mon, Jun 25, 2012 at 5:28 PM, Doug Hellmann doug.hellm...@dreamhost.com wrote: On Mon, Jun 25, 2012 at 6:19 PM, Ken Thomas k...@yahoo-inc.com wrote: [...] I've already submitted the keystone changes for review (https://review.openstack.org/#/c/8958/3/keystoneclient/shell.py) and I'd be happy to make the same change to UnifiedCLI as well. Thanks, Ken! That sounds like a good change to make. If you add me as a reviewer on the patch, I'll make sure to look at the changes. I created a blueprint for this: https://blueprints.launchpad.net/python-openstackclient/+spec/password-prompt linking back to the keystone blueprint. That looks like a good solution. Thanks Ken dt Probably would be better to have a deliberate command line flag for it, so automated scripts don't hang. Something like --prompt ___ 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
[Openstack] UnifiedCLI suggestion
Greetings all, Our security folks have an issue with putting passwords on the command line or in the environment. I wrote up a blueprint that gives the details on their objections as well as a proposed short-term fix for keystone (https://blueprints.launchpad.net/keystone/+spec/prompt-for-password). We'd like to see this same change get into UnifiedCLI as a longer term fix. The change is minor. If no password was found on the command line or in the env, just before the expecting password error is raised, we make an attempt to prompt the user for it. If we get something, great! Our security folks are happy and we keep processing. If we don't get the password for any number of reasons (keystone wasn't being run from a tty, the user hit Ctrl-C or Ctrl-D when prompted), then we raise the error just as before. I've already submitted the keystone changes for review (https://review.openstack.org/#/c/8958/3/keystoneclient/shell.py) and I'd be happy to make the same change to UnifiedCLI as well. 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
[Openstack] Any issue with pycurl?
Hi all, We're working on a custom plugin where we make a web service call. We're having some issues with urllib2 and httplib that we're trying to track down. In the meantime, we've discovered that it all works fine if we use pycurl. If we don't suss out the problem, does anybody know if there are any interaction issues with pycurl being used in a nova plugin? 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
[Openstack] Flags.add_option rename issue
Hi all, The same sort of problem that I saw on Jan 30 (see below) has happened again. Specifically, nova flags.py recently changed where method add_option was renamed to register_opt. The nova files were all updated but one file in noVNC (from a different github repository) was not, and so now novnc won't start. To paraphrase my original question... Do I open an issue on nova for not catching all the uses of that method, or on cloudbuilders/noVNC to get it to work with the latest nova flags? Thanks, Ken On 1/30/12 4:14 PM, Ken Thomas wrote: Greetings all, I'm having an issues with nova-novncproxy where it's using nova flags.DEFINE* helpers, but I see that those helpers were refactored away last week. I know that these are two different github repositories so I'm not sure who needs to fix this. Do I open an issue on nova to get them back or open an issue on cloudbuilders/noVNC to remove the usage? 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
