openstack team mailing list archive
-
openstack team
-
Mailing list archive
-
Message #13231
Re: [Blueprint automatic-secure-key-generation] Automatic SECURE_KEY generation
-
To:
Gabriel Hurley <gabriel.hurley@xxxxxxxxxx>
-
From:
Sascha Peilicke <saschpe@xxxxxxx>
-
Date:
Fri, 15 Jun 2012 09:37:33 +0200
-
Cc:
openstack@xxxxxxxxxxxxxxxxxxx
-
In-reply-to:
<20120614203620.28369.3866.launchpad@soybean.canonical.com>
-
Organization:
SUSE Linux GmbH
-
User-agent:
Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120601 Thunderbird/13.0
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/1414d538d65d2d3deb981db0ab9e888a3c96a149
--
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)
Attachment:
signature.asc
Description: OpenPGP digital signature
Follow ups