Open Stack

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.

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.

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

    - 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)
>