Re: How to best secure environment variables (secret key, passwords etc.) stored in .yml files?
Thanks everyone for responding to this question. Nice to know (in a way) that I'm not overthinking it.. although now I'm worried about all the different ways a key could be compromised. Your suggestions for separating out a .env file and using gitignore is really helpful. Tom On Thursday, January 30, 2020 at 8:01:59 PM UTC, Michael Rohan wrote: > > Hi, > > Just fyi, it was, in part, to solve this problem that I implemented the > django-yamlconf module: > > https://django-yamlconf.readthedocs.io/en/latest/ > > While getting the data into either a private yaml file or env variable in > the container isn't addressed, it does allow injecting the values into the > Django app without modifying the committed sources. > > Take care, > Michael. > > On Thu, Jan 30, 2020 at 6:46 AM Chris Wedgwood > wrote: > >> Hi Tom >> >> You are definitely not overthinking this. it's important. >> >> This is an area that has baked my noodle for a while now and I always am >> left wondering "Do I have this right?" "Am I vulnerable to attack?" . >> and I still haven't figured it out completely. It's like static files I >> never really feeel like I get it entirely :) >> >> Firstly you should never need to store a password/token/secret in Source >> Control ever. If you are stop and think there must be a better way. >> >> I use environment variables .env to store my secrets but the trick is >> ALWAYS put that in your .gitignore file. If you start a new git repository >> there is an option to create a .gitignore file >> for Python that is a great starting point. >> >> To complement my *.env* file it has a .env.example file that I DO put in >> source control with a dummy password. >> >> .env file: >> >> MAILGUN_API_KEY =asjdhasds78dy9s8dy012287e210eu209e72 >> >> .env.example: >> >> MAILGUN_API_KEY=ThisIsNotARealToken >> >> So when I do local development I can populate my .env fie with local dev >> secrets. >> >> For production deployments, I use *Ansible *for which I provide >> production tokens and secrets in a separate file also not in source control. >> >> The Ansible deployment requires an ssh password that I store in a >> Password Manager that has two-factor authentication. >> >> The docker-compose file can read environment variables from the .env file. >> >> Have a look at Django-Cookiecutter and see how they do it. That helped me >> a lot when I started out >> >> cheers >> Chris >> >> >> >> >> >> >> >> >> >> >> >> On Thursday, 30 January 2020 12:41:01 UTC, Tom Moore wrote: >>> >>> Hi there, I'm following the guidelines by making sure the environment >>> variables are stored outside of the settings.py files. >>> >>> The project is "dockerised" and so the environment variables have been >>> stored in files *docker-compose.yml* and *docker-compose-prod.yml*. >>> >>> This includes things like the project's secret key, API keys, and >>> database passwords. >>> >>> *My question is: * >>> • Just because environment variables are stored in .yml files, won't >>> they be equally insecure the moment I commit the project folder to a git >>> repo (and especially if I push that repo to GitHub)? >>> e.g. the Secret Key will forevermore be stored in the git repo (in >>> earlier versions, even if I later move it to another file in subsequent >>> commits). >>> >>> Is there an even more secure way of storing environment variables? Or am >>> I overthinking it (as I'm the only developer and the GitHub repo is set to >>> Private)? >>> >>> Many thanks in advance for your help. >>> >> -- >> You received this message because you are subscribed to the Google Groups >> "Django users" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to django...@googlegroups.com . >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/django-users/55f28dec-7c9a-4cae-b658-f89772aa1bd7%40googlegroups.com >> >> <https://groups.google.com/d/msgid/django-users/55f28dec-7c9a-4cae-b658-f89772aa1bd7%40googlegroups.com?utm_medium=email_source=footer> >> . >> > > > -- > Michael Rohan > mro...@acm.org > -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/e54a3ad3-1df3-49aa-8ae0-7378f3c91ace%40googlegroups.com.
Re: What's a recommended/common approach to staging and production apps in Heroku, using Docker containers?
Hi Alvaro, Thanks very much for the suggestion, nice to understand how two containers can be set up to interact with each other. Tom On Thursday, January 30, 2020 at 1:10:02 PM UTC, Álvaro Durán wrote: > > Hi Tom, > I had a similar problem a while ago using React and Django as separate > containers, this tutorial helped me very much: > https://dev.to/englishcraig/creating-an-app-with-docker-compose-django-and-create-react-app-31lf > > I'm not aware whether that's suitable to your case, but if it is so, I put > together a cookiecutter based on that tutorial that you may want to have a > look at if you fancy: https://github.com/ohduran/cookiecutter-react-django > > Happy to hear comments from other people on the quality of this tutorial > while using Heroku. > > Alvaro. > > On Thursday, 30 January 2020 13:41:01 UTC+1, Tom Moore wrote: >> >> Hi there, >> >> >> I'm trying to set up *staging* and *production* apps in Heroku. Nothing >> fancy, just a way to test the app is running okay on Heroku's platform >> before it gets pushed to production. >> >> >> The project is containerised in Docker. >> >> >> I've tried setting up a pipeline in Heroku, but when I click "promote to >> production" on the staging app, Heroku displays an error saying that action >> is not supported for docker containers. >> >> >> If that's true (and Docker is still popular), what is a recommended >> workflow for this? >> >> >> The only workaround I can think of is to simply have two apps running in >> Heroku (*project-name-staging* and *project-name-production*) and just >> push the codebase to one and then the other manually from my local machine. >> But surely there's a better way. >> >> >> Thanks very much in advance for your help. >> > -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/bccd01d8-942e-487b-b4cd-0efa957cf99f%40googlegroups.com.
How to best secure environment variables (secret key, passwords etc.) stored in .yml files?
Hi there, I'm following the guidelines by making sure the environment variables are stored outside of the settings.py files. The project is "dockerised" and so the environment variables have been stored in files *docker-compose.yml* and *docker-compose-prod.yml*. This includes things like the project's secret key, API keys, and database passwords. *My question is: * • Just because environment variables are stored in .yml files, won't they be equally insecure the moment I commit the project folder to a git repo (and especially if I push that repo to GitHub)? e.g. the Secret Key will forevermore be stored in the git repo (in earlier versions, even if I later move it to another file in subsequent commits). Is there an even more secure way of storing environment variables? Or am I overthinking it (as I'm the only developer and the GitHub repo is set to Private)? Many thanks in advance for your help. -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/887bcd5b-4525-4a54-a4e5-5eae32b20041%40googlegroups.com.
What's a recommended/common approach to staging and production apps in Heroku, using Docker containers?
Hi there, I'm trying to set up *staging* and *production* apps in Heroku. Nothing fancy, just a way to test the app is running okay on Heroku's platform before it gets pushed to production. The project is containerised in Docker. I've tried setting up a pipeline in Heroku, but when I click "promote to production" on the staging app, Heroku displays an error saying that action is not supported for docker containers. If that's true (and Docker is still popular), what is a recommended workflow for this? The only workaround I can think of is to simply have two apps running in Heroku (*project-name-staging* and *project-name-production*) and just push the codebase to one and then the other manually from my local machine. But surely there's a better way. Thanks very much in advance for your help. -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/f840735e-2833-4f8e-bb94-ebc3beb90b4e%40googlegroups.com.
