How to I hide my secret_key using virtualenv and Django?

Question

I am using Django, python, virtualenv, virtualenvwrapper and Vagrant.

So far I have simply left my secret_key inside of the settings.py file. This works file for local files. However I have already placed my files in Git. I know this is not acceptable for production(Apache).

What is the correct way to go about hiding my secret_key?

Should I use virtualenv to hide it?

Answer 1

There's a lot of different methods to hide secrets.

1. Use another, non-versioned file.

   Create a new file secrets.py or what have you and put your secrets in that. Place it alongside your settings file and place everything secret in there; then in your settings file put from secrets import * at the top. Then, like Rahul said, add a .gitignore file and add secrets.py to this file so that it won't be committed.

   The disadvantage of this approach is that there is no source control at all on that file; if you lose it you're SOL.

2. Use environment variables.

   Use the Apache SetEnv or PassEnv directives to pass environment variables to your process, then retrieve them with os.environ() in your settings file. This has the advantage in that in development, you can set new variables (as simply as VAR1=whatever VAR2=whatever ... ./manage.py runserver ...) or set them from whatever mechanism you use to launch your development project.

   The disadvantage is much the same; if you lose your Apache configs you're boned.

3. Use a second repository in combination with method 1.

   Personally, I like the idea of having a dedicated secrets repository that you put all your secrets into and keep that repo under lock and key. Then as part of your deployment process, you can use git archive or another similar command to extract the proper keys for the place you're deploying to, and you can keep your secrets backed up and under version control easily. You can also add the appropriate files in the secrets repo to the .gitingore file of your site repository so that they don't accidentally get committed.

   The downside of this is that you have another extra repository and another deployment step. I think that's worth it, personally, but it's really up to you.

In general, the more secure you want it, the more inconvenient it's going to be to access those secrets. That's really a rule in general, though.