[Openstack] New build dependency on keyring

Ken Thomas krt at yahoo-inc.com
Thu Dec 13 14:50:38 UTC 2012


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 <krt at 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 <krt at 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 at lists.launchpad.net
>>>> Unsubscribe : https://launchpad.net/~openstack
>>>> More help   : https://help.launchpad.net/ListHelp





More information about the Openstack mailing list