Open Stack

On 06/15/2012 11:08 PM, Gabriel Hurley wrote:
> To the points Sascha raised, and in particular in response to the code method suggested here (https://github.com/saschpe/horizon/commit/1414d538d65d2d3deb981db0ab9e888a3c96a149) I think we are largely in agreement except for one point:
> 
> I have no problem with this approach for development, or even for distro packaging, but I strongly dislike this automatic generation for a production deployment. Particularly there are issues about distributed deployments where the installs need to share a common secret key to allow for shared data signing validation, etc. I would rather not obfuscate these very real and very relevant concerns for productions deployments for the sake of making everything else a little easier. Especially because it will lead to very hard-to-diagnose bugs because people aren't aware of the magic happening behind the scenes.

Ah, you're thinking of a setup where there are multiple dashboard VMs
behind a load-balancer serving requests. Indeed, there the dashboard
instances should either share the SECRET_KEY or the load-balancer has to
make sure that all requests of a given session are redirected to the
same dashboard instance.

But shouldn't local_settings.py still take preference over settings.py?
Thus the admin could still set a specific SECRET_KEY in
local_settings.py regardless of the default (auto-generated) one. So I
only would have to fix the patch by not removing the documentation about
SECRET_KEY from local_settings.py, right?


> As such, I'd rather have the code you wrote be part of the environment build/run_tests code such that there's an *optional* tool to do this, but it doesn't hide legitimate security and functionality concerns.

Unfortunately, this is only relevant for securing production
deployments. Nobody cares if a developer instance is setup securely ;-)

> I'm also cc'ing Paul McMillan, Django's resident security expert, to get his take on this.

Have you already got an answer from Paul? He wan't in the CC list, actually.

> 
>     - Gabriel
> 
>> -----Original Message-----
>> From: Sascha Peilicke [mailto:saschpe at suse.de]
>> Sent: Friday, June 15, 2012 12:38 AM
>> To: Gabriel Hurley
>> Cc: openstack at lists.launchpad.net
>> Subject: Re: [Blueprint automatic-secure-key-generation] Automatic
>> SECURE_KEY generation
>>
>> Hi Grabriel,
>>
>> let's discuss the blueprint [1] on the list.
>>
>> On 06/14/2012 10:36 PM, Gabriel Hurley wrote:
>>> Blueprint changed by Gabriel Hurley:
>>>
>>> Whiteboard set to:
>>> After discussing this with both the Horizon core team and Django's
>>> security czar/core committer Paul McMillan, we've decided the best way
>>> to proceed with this is as follows:
>>>
>>>   * Remove the default SECRET_KEY so it cannot be shared causing security
>> problems.
>>>   * For development, add a few lines to auto-generate a SECRET_KEY if one
>> isn't present.
>> Ok, nothing to add, this is what the patch actually does [2].
>>
>>>   * For production, document that a SECRET_KEY is required, how to
>> generate one, etc.
>> The question to me is, why this should matter to the admin at all.
>> Security-wise, the only thing that matters is that the SECRET_KEY is unique
>> per dashboard installation and set before the first start.
>> Whether this is done by the admin or by the patch to discuss doesn't really
>> matter. However, even if documented appropriately, setting up a complete
>> OpenStack deployment isn't exactly a piece of cake. Having to remember yet
>> another config value is error-prone IMO and easily forgotten. Actually,
>> Django already does a really good job in documenting this, but we stumbled
>> upon this because all of our internal development clouds had the same
>> (default) SECRET_KEY. Seems like we just forgot ;-)
>>
>>>   * Work with the distros to make sure they properly generate a unique
>> SECRET_KEY for each install.
>> This is why I started the whole topic, as there are cases where this is just
>> impractical. But let's take it slowly, current OpenStack rpm packages for
>> openSUSE / SLES generate a SECRET_KEY as a %post scriptlet (i.e. just after
>> package installation). This doesn't hurt and is probably what you had in mind.
>> However, this only works if there is actually a package to install.
>>
>> Unfortunately, this isn't the case when the dashboard is deployed from an
>> appliance image. Of course, you could check and set the SECRET_KEY after
>> successfully booting up the appliance image via a script (if it is not a snapshot
>> of an already booted system) or you could just do it when the Django app is
>> actually started. The latter seems more practical to me. And lastly, when it's
>> part of the horizon code-base, the issue could be solved for all deployments.
>>
>> Footnotes:
>>  [1]
>> https://blueprints.launchpad.net/horizon/+spec/automatic-secure-key-
>> generation
>>  [2]
>> https://github.com/saschpe/horizon/commit/1414d538d65d2d3deb981db0a
>> b9e888a3c96a149
>>
>> --
>> With kind regards,
>> Sascha Peilicke
>> SUSE Linux GmbH, Maxfeldstr. 5, D-90409 Nuernberg, Germany
>> GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer HRB 16746 (AG Nürnberg)
>>
> 
> _______________________________________________
> 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
> 


-- 
With kind regards,
Sascha Peilicke
SUSE Linux GmbH, Maxfeldstr. 5, D-90409 Nuernberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer HRB 16746 (AG Nürnberg)



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20120618/ccfa57b7/attachment.sig>