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:sasc...@suse.de] >> Sent: Friday, June 15, 2012 12:38 AM >> To: Gabriel Hurley >> Cc: openstack@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@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)
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp