Handling secret keys in digitalocean
372 views
Skip to first unread message
yingi keme
Jan 10, 2018, 4:34:03 AM1/10/18
to Django users
I am aware that its a bad idea to put your secret keys and other API keys in your settinggs.py file.
In a production environment like for instance hosting your site in digitalocean, where will you have to store your secret keys. And how will you load it in your settings.py file.?
I am a newbie when it comes to deploying, anyhelp will please.!!!
Antonis Christofides
Jan 10, 2018, 6:12:12 AM1/10/18
to django...@googlegroups.com
Hello,
this is actually a big question that is a pain for lots of people. The other
time I held a webinar and I spent some time on this; if you are interested it's
at https://www.crowdcast.io/e/deploying-django, and together with the related
question about different settings in development vs. deployment, I start
treating this issue at 38m10s.
Regards,
Antonis
Antonis Christofides
http://djangodeployment.com
this is actually a big question that is a pain for lots of people. The other
time I held a webinar and I spent some time on this; if you are interested it's
at https://www.crowdcast.io/e/deploying-django, and together with the related
question about different settings in development vs. deployment, I start
treating this issue at 38m10s.
Regards,
Antonis
Antonis Christofides
http://djangodeployment.com
Etienne Robillard
Jan 10, 2018, 6:21:23 AM1/10/18
to django...@googlegroups.com
Hi,
I think this is paranoia. Unless you allow root access to your droplet
without password or pubkey authentication, there's no way anyone can
gain access to your settings.py file.
cheers,
Etienne
--
Etienne Robillard
tka...@yandex.com
https://www.isotopesoftware.ca/
I think this is paranoia. Unless you allow root access to your droplet
without password or pubkey authentication, there's no way anyone can
gain access to your settings.py file.
cheers,
Etienne
Etienne Robillard
tka...@yandex.com
https://www.isotopesoftware.ca/
Jason
Jan 10, 2018, 9:01:18 AM1/10/18
to Django users
Etienne, I think this is more related to having secrets outside of your code repository than actually on the server. Having your AWS and db creds in your github repo, whether public or private, is a pretty bad thing to do.
Etienne Robillard
Jan 10, 2018, 2:36:48 PM1/10/18
to Jason, django...@googlegroups.com
Hi Jason,
I understand your views. But I have trust in Digital Ocean and Github that they will not mess with "private" stuff unless they want to expose themselves to lawsuits.
Personally, I don't care using a code repository to save
Django-specific data.
Cheers,
Etienne
Le 2018-01-10 à 09:01, Jason a écrit :
Etienne, I think this is more related to having secrets outside of your code repository than actually on the server. Having your AWS and db creds in your github repo, whether public or private, is a pretty bad thing to do.
--
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...@googlegroups.com.
To post to this group, send email to django...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/52e78880-3127-42c3-b2de-50a451b22072%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
yingi keme
Jan 10, 2018, 3:22:33 PM1/10/18
to django...@googlegroups.com
Hi jason,
Ok so do you suggest moving secret keys to an environment variable because i am seeing tutorials on that, but its typically on the development stage. In production level, how will you do that..?
Yingi Kem
Yingi Kem
Etienne, I think this is more related to having secrets outside of your code repository than actually on the server. Having your AWS and db creds in your github repo, whether public or private, is a pretty bad thing to do.
--
yingi keme
Jan 10, 2018, 3:24:46 PM1/10/18
to django...@googlegroups.com
Hi Etienne,
I will thoroughly investigate which is the best approach.
Yingi Kem
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/f28057cd-c300-c8e4-dbe7-52d155328db3%40yandex.com.
Jason
Jan 10, 2018, 5:04:40 PM1/10/18
to Django users
Since my work stuff is on Apache, I use this advice from two scoops of django.
Etienne, are you really saying you have your AWS and database credentials, usernames and passwords in your project repositories? ouch
Jason
Jan 10, 2018, 5:06:47 PM1/10/18
to Django users
Etienne Robillard
Jan 10, 2018, 5:13:36 PM1/10/18
to Jason, django...@googlegroups.com
Le 2018-01-10 à 17:04, Jason a écrit :
Since my work stuff is on Apache, I use this advice from two scoops of django.
Etienne, are you really saying you have your AWS and database credentials, usernames and passwords in your project repositories? ouch
I dont save clear-text passwords in Django settings for security
reasons.
Except I don't mind putting API keys and Django-specific data like SECRET_KEY inside a private code repository.
Cheers,
Etienne
Except I don't mind putting API keys and Django-specific data like SECRET_KEY inside a private code repository.
Cheers,
Etienne
--
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...@googlegroups.com.
To post to this group, send email to django...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/829ffc12-1ffa-4dba-b8ee-4ad25db74ae0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Joe
Jan 10, 2018, 6:02:36 PM1/10/18
to Django users
In addition to all of the reasons Jason posted, a private GitHub repository does not guarantee you any security of your data. From https://help.github.com/articles/github-terms-of-service/ :
"GitHub does not warrant that the Service will meet your requirements; that the Service will be uninterrupted, timely, secure, or error-free; that the information provided through the Service is accurate, reliable or correct..."
Additionally: "You understand and agree that we will not be liable to you or any third party for any loss of profits, use, goodwill, or data, or for any incidental, indirect, special, consequential or exemplary damages, however arising, that result from
the use, disclosure, or display of your User-Generated Content;
your use or inability to use the Service;
any modification, price change, suspension or discontinuance of the Service;
the Service generally or the software or systems that make the Service available;
unauthorized access to or alterations of your transmissions or data;
statements or conduct of any third party on the Service;
any other user interactions that you input or receive through your use of the Service; or
any other matter relating to the Service."
On top of this, it is a security anti-pattern and a generally accepted poor practice to store private data in any repository. In fact, that is enough to fail an audit with some compliance levels.
Mike Dewhirst
Jan 10, 2018, 6:43:38 PM1/10/18
to Django users
My requirements are to keep sensitive items out of the repositories and
that means out of settings.
I keep a separate directory structure for settings as recommended in 2
Scoops. That means the code in my project has to detect which site it is
running on (local, staging or production) and then load the settings
file for that site.
Since as it knows whether it is local, staging or production I can
leverage that to find credentials and other sensitive stuff in files
stored safely on disk and named for their content in a directory named
local, staging or production.
I wrote a little python program getcreds.py to go fetch the data as
required in settings.
Works for me.
Cheers
Mike
#getcreds.py
# -*- coding: utf-8 -*-
# Copyright (C) 2017 Climate Pty Ltd
# This is free software subject to the terms of the GNU GPL v3
"""
getcreds returns secret info which should never be stored in a
repository. For example, username and password etc.
It requires a credsroot directory to already exist and also a project
sub-directory to contain text files holding the required secret
information. Other secret info would be in other project sub-dirs.
When called with project="xyz" and credsroot="/var/www/creds" (the
default), it joins them to discover credsdir in which it looks for
fname which contains the secret info. Otherwise, if you supply the
entire credsdir eg "/var/www/creds/xyz" it will use that instead.
Forward slashes always work on Windows in Python code. Otherwise
use doubled backslashes eg "\\var\\www\\creds\\xyz"
Each line of the named text file (fname) will be read into a list
with the first line in the zero'th element of the list ie creds[0]
In your code requiring credentials or other secret info for example:
from .getcreds import getcreds
...
credslist = getcreds("db.host", project="xyz")
database_host = credslist[0]
database_port = credslist[1]
database_user = credslist[2]
database_pass = credslist[3]
# now establish a database connection
...
Provided you have established appropriate read permissions in credsdir
the secrets are protected. Because they never appear in your code they
stay out of the repository so that many years hence they cannot be
discovered under any nefarious circumstances.
"""
from __future__ import unicode_literals, absolute_import, division
import os
def getcreds(fname, project, credsroot='/var/www/creds', credsdir=None):
""" return a list of userid and password and perhaps other data """
if credsdir is None:
credsdir = os.path.join(credsroot, project)
creds = list()
fname = os.path.join(credsdir, fname).replace("\\", "/")
with open(fname, 'r') as f:
for line in f:
# remove leading/trailing whitespace and append to list
creds.append(line.strip())
assert creds, "The list of credentials is empty"
return creds
On 11/01/2018 7:20 AM, yingi keme wrote:
> Hi jason,
>
> Ok so do you suggest moving secret keys to an environment variable
> because i am seeing tutorials on that, but its typically on the
> development stage. In production level, how will you do that..?
>
> Yingi Kem
>
> On 10 Jan 2018, at 3:01 PM, Jason <jjohn...@gmail.com
> <https://groups.google.com/d/msgid/django-users/83521899-2750-46CA-9F31-B63BA827724B%40gmail.com?utm_medium=email&utm_source=footer>.
that means out of settings.
I keep a separate directory structure for settings as recommended in 2
Scoops. That means the code in my project has to detect which site it is
running on (local, staging or production) and then load the settings
file for that site.
Since as it knows whether it is local, staging or production I can
leverage that to find credentials and other sensitive stuff in files
stored safely on disk and named for their content in a directory named
local, staging or production.
I wrote a little python program getcreds.py to go fetch the data as
required in settings.
Works for me.
Cheers
Mike
#getcreds.py
# -*- coding: utf-8 -*-
# Copyright (C) 2017 Climate Pty Ltd
# This is free software subject to the terms of the GNU GPL v3
"""
getcreds returns secret info which should never be stored in a
repository. For example, username and password etc.
It requires a credsroot directory to already exist and also a project
sub-directory to contain text files holding the required secret
information. Other secret info would be in other project sub-dirs.
When called with project="xyz" and credsroot="/var/www/creds" (the
default), it joins them to discover credsdir in which it looks for
fname which contains the secret info. Otherwise, if you supply the
entire credsdir eg "/var/www/creds/xyz" it will use that instead.
Forward slashes always work on Windows in Python code. Otherwise
use doubled backslashes eg "\\var\\www\\creds\\xyz"
Each line of the named text file (fname) will be read into a list
with the first line in the zero'th element of the list ie creds[0]
In your code requiring credentials or other secret info for example:
from .getcreds import getcreds
...
credslist = getcreds("db.host", project="xyz")
database_host = credslist[0]
database_port = credslist[1]
database_user = credslist[2]
database_pass = credslist[3]
# now establish a database connection
...
Provided you have established appropriate read permissions in credsdir
the secrets are protected. Because they never appear in your code they
stay out of the repository so that many years hence they cannot be
discovered under any nefarious circumstances.
"""
from __future__ import unicode_literals, absolute_import, division
import os
def getcreds(fname, project, credsroot='/var/www/creds', credsdir=None):
""" return a list of userid and password and perhaps other data """
if credsdir is None:
credsdir = os.path.join(credsroot, project)
creds = list()
fname = os.path.join(credsdir, fname).replace("\\", "/")
with open(fname, 'r') as f:
for line in f:
# remove leading/trailing whitespace and append to list
creds.append(line.strip())
assert creds, "The list of credentials is empty"
return creds
On 11/01/2018 7:20 AM, yingi keme wrote:
> Hi jason,
>
> Ok so do you suggest moving secret keys to an environment variable
> because i am seeing tutorials on that, but its typically on the
> development stage. In production level, how will you do that..?
>
> Yingi Kem
>
> On 10 Jan 2018, at 3:01 PM, Jason <jjohn...@gmail.com
> <mailto:jjohn...@gmail.com>> wrote:
>
>> Etienne, I think this is more related to having secrets outside of
>> your code repository than actually on the server. Having your AWS
>> and db creds in your github repo, whether public or private, is a
>> pretty bad thing to do.
>> --
>> 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...@googlegroups.com
>> <mailto:django-users...@googlegroups.com>.
>
>> Etienne, I think this is more related to having secrets outside of
>> your code repository than actually on the server. Having your AWS
>> and db creds in your github repo, whether public or private, is a
>> pretty bad thing to do.
>> --
>> 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...@googlegroups.com
>> To post to this group, send email to django...@googlegroups.com
>> <mailto:django...@googlegroups.com>.
>> Visit this group at https://groups.google.com/group/django-users.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-users/52e78880-3127-42c3-b2de-50a451b22072%40googlegroups.com
>> <https://groups.google.com/d/msgid/django-users/52e78880-3127-42c3-b2de-50a451b22072%40googlegroups.com?utm_medium=email&utm_source=footer>.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-users/52e78880-3127-42c3-b2de-50a451b22072%40googlegroups.com
>> For more options, visit https://groups.google.com/d/optout.
> --
> 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...@googlegroups.com
> <mailto:django-users...@googlegroups.com>.
> 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...@googlegroups.com
> To post to this group, send email to django...@googlegroups.com
> <mailto:django...@googlegroups.com>.
> Visit this group at https://groups.google.com/group/django-users.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-users/83521899-2750-46CA-9F31-B63BA827724B%40gmail.com
> To view this discussion on the web visit
> <https://groups.google.com/d/msgid/django-users/83521899-2750-46CA-9F31-B63BA827724B%40gmail.com?utm_medium=email&utm_source=footer>.
Reply all
Reply to author
Forward
0 new messages