How do I store details securely with django?

Discussion:

Lance Haig

2018-11-11 13:47:13 UTC

Hi,

I have a project I am working on https://github.com/lhaig/usery/ and
part of the roadmap of the project is to add more cloud types to the list.

I wanted to allow admins for these services to login and create records
for their different clouds in the DB and then use these when people
request access to these services.

I need to find a secure way to store these credentials so that even if
the DB is compromised that the credentials are safe.

Does anyone have suggestions on how I can accomplish this?

I would really appreciate some advice.

Regards

Lance

--
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/8cd7b01e-c38d-1abd-e163-dedd7eca6e78%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Mike Dewhirst

2018-11-11 22:07:14 UTC

Permalink

Post by Lance Haig
Hi,
I have a project I am working on https://github.com/lhaig/usery/ and
part of the roadmap of the project is to add more cloud types to the list.
I wanted to allow admins for these services to login and create
records for their different clouds in the DB and then use these when
people request access to these services.
I need to find a secure way to store these credentials so that even if
the DB is compromised that the credentials are safe.

I agree credentials should not be stored in the database but what are
your other assumptions about the threats?

How many sets of credentials will there be?

In future, will you be using simple credentials or tokens, certificates,
multi factor auth?

If this is a prototype and only a few sets are involved you can store
credentials in a file or one file per set and write a method to fetch
them as required. That will keep them out of the database and let you
rejig the method after you have decided how it should really work.

Post by Lance Haig
Does anyone have suggestions on how I can accomplish this?
I would really appreciate some advice.
Regards
Lance

--
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/c8819341-7c60-56ee-6298-3a6a7897e9b1%40dewhirst.com.au.
For more options, visit https://groups.google.com/d/optout.

PASCUAL Eric

2018-11-11 23:03:47 UTC

Permalink

Hi,

It can depend on which deployment option you plan to use for the application.

For instance, a Docker deployment orchestrated by Kubernetes gives the option of using secrets for sensitive information, which a hoster such as GCP manages conveniently. In this kind of deployment, configuration (and secrets) are passed to the app as environment variables, on which Kubernetes configuration maps and secrets are mapped to. Thanks to this, values are stored nowhere in the app code, companion files or database.

Regards

Eric

________________________________
From: django-***@googlegroups.com <django-***@googlegroups.com> on behalf of Mike Dewhirst <***@dewhirst.com.au>
Sent: Sunday, November 11, 2018 11:07:14 PM
To: django-***@googlegroups.com
Subject: Re: How do I store details securely with django?

Post by Lance Haig
Hi,
I have a project I am working on https://github.com/lhaig/usery/ and
part of the roadmap of the project is to add more cloud types to the
list.
I wanted to allow admins for these services to login and create
records for their different clouds in the DB and then use these when
people request access to these services.
I need to find a secure way to store these credentials so that even if
the DB is compromised that the credentials are safe.

Post by Lance Haig
Does anyone have suggestions on how I can accomplish this?
I would really appreciate some advice.
Regards
Lance

--
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/c8819341-7c60-56ee-6298-3a6a7897e9b1%40dewhirst.com.au.
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.
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/VI1P193MB043243D0747282C2D96F60E38CC00%40VI1P193MB0432.EURP193.PROD.OUTLOOK.COM.
For more options, visit https://groups.google.com/d/optout.

Lance Haig

2018-11-12 08:07:30 UTC

Permalink

Hi Eric,

Thanks for the response.

This idea has an end goal of being deployed in a resilient way so most
probably docker with some form of orchestration, Docker swarm or Kubernetes.

The credentials are mainly stored in a .env file at the moment and could
be added to the secrets but I need for people who are admins for a
particular cloud to add their cloud details to the app and then store
their credentials securely.

Unfortunately this will need a dynamic storage mechanism which i don't
know how to do yet

Regards

Lance

Post by PASCUAL Eric
Hi,
It can depend on which deployment option you plan to use for the application.
For instance,Â a Docker deployment orchestrated by Kubernetes gives the
option of using secrets for sensitive information, which a hoster such
as GCP manages conveniently. In this kind of deployment, configuration
(and secrets) are passed to the app as environment variables, on which
Kubernetes configuration maps and secrets are mapped to. Thanks to
this, values are stored nowhere in the app code, companion files or
database.
Regards
Eric
------------------------------------------------------------------------
*Sent:* Sunday, November 11, 2018 11:07:14 PM
*Subject:* Re: How do I store details securely with django?

I agree credentials should not be stored in the database but what are
your other assumptions about the threats?
How many sets of credentials will there be?
In future, will you be using simple credentials or tokens, certificates,
multi factor auth?
If this is a prototype and only a few sets are involved you can store
credentials in a file or one file per set and write a method to fetch
them as required. That will keep them out of the database and let you
rejig the method after you have decided how it should really work.

Post by Lance Haig
Does anyone have suggestions on how I can accomplish this?
I would really appreciate some advice.
Regards
Lance

--
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
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/c8819341-7c60-56ee-6298-3a6a7897e9b1%40dewhirst.com.au.
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
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/VI1P193MB043243D0747282C2D96F60E38CC00%40VI1P193MB0432.EURP193.PROD.OUTLOOK.COM
<https://groups.google.com/d/msgid/django-users/VI1P193MB043243D0747282C2D96F60E38CC00%40VI1P193MB0432.EURP193.PROD.OUTLOOK.COM?utm_medium=email&utm_source=footer>.
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.
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/478ff804-4204-54c2-ba62-c0e4f9d64f89%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

PASCUAL Eric

2018-11-12 09:04:30 UTC

Permalink

Hi Lance,

but I need for people who are admins for a particular cloud to add their cloud details to the app and then store their credentials securely.

I'm not sure to understand the need for adding cloud details to the app for the admins.

The suggestion I made assumed that sensitive information is managed as K8S secrets. As long as the admins have GCloud (for instance) credentials set (which are stored and managed at GCloud level), they can administrate the secrets resources by "applying" the corresponding YAML descriptors remotely from their workstation. The sensitive values are thus stored nowhere inside the application itself, but passed to the containers at runtime as environment variables.

Maybe I've misunderstood your need and sorry in this case if my answer is off topic.

Best

Eric

________________________________
From: django-***@googlegroups.com <django-***@googlegroups.com> on behalf of Lance Haig <***@gmail.com>
Sent: Monday, November 12, 2018 9:07:30 AM
To: django-***@googlegroups.com
Subject: Re: How do I store details securely with django?

Hi Eric,

Thanks for the response.

This idea has an end goal of being deployed in a resilient way so most probably docker with some form of orchestration, Docker swarm or Kubernetes.

The credentials are mainly stored in a .env file at the moment and could be added to the secrets but I need for people who are admins for a particular cloud to add their cloud details to the app and then store their credentials securely.

Unfortunately this will need a dynamic storage mechanism which i don't know how to do yet

Regards

Lance

On 11/12/18 12:03 AM, PASCUAL Eric wrote:

Hi,

It can depend on which deployment option you plan to use for the application.

For instance, a Docker deployment orchestrated by Kubernetes gives the option of using secrets for sensitive information, which a hoster such as GCP manages conveniently. In this kind of deployment, configuration (and secrets) are passed to the app as environment variables, on which Kubernetes configuration maps and secrets are mapped to. Thanks to this, values are stored nowhere in the app code, companion files or database.

Regards

Eric

________________________________
From: django-***@googlegroups.com<mailto:django-***@googlegroups.com> <django-***@googlegroups.com><mailto:django-***@googlegroups.com> on behalf of Mike Dewhirst <***@dewhirst.com.au><mailto:***@dewhirst.com.au>
Sent: Sunday, November 11, 2018 11:07:14 PM
To: django-***@googlegroups.com<mailto:django-***@googlegroups.com>
Subject: Re: How do I store details securely with django?

Post by Lance Haig
Does anyone have suggestions on how I can accomplish this?
I would really appreciate some advice.
Regards
Lance

--
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/VI1P193MB0432916809AFE450553011D98CC10%40VI1P193MB0432.EURP193.PROD.OUTLOOK.COM.
For more options, visit https://groups.google.com/d/optout.

Pradeep Singh

2018-11-12 11:28:43 UTC

Permalink

can i develop real estate web application using python+ django

Post by PASCUAL Eric
Hi Lance,
but I need for people who are admins for a particular cloud to add their
cloud details to the app and then store their credentials securely.
I'm not sure to understand the need for adding cloud details to the app for the admins.
The suggestion I made assumed that sensitive information is managed as K8S
secrets. As long as the admins have GCloud (for instance) credentials set
(which are stored and managed at GCloud level), they can administrate the
secrets resources by "applying" the corresponding YAML descriptors
remotely from their workstation. The sensitive values are thus stored
nowhere inside the application itself, but passed to the containers at
runtime as environment variables.
Maybe I've misunderstood your need and sorry in this case if my answer is off topic.
Best
Eric
------------------------------
*Sent:* Monday, November 12, 2018 9:07:30 AM
*Subject:* Re: How do I store details securely with django?
Hi Eric,
Thanks for the response.
This idea has an end goal of being deployed in a resilient way so most
probably docker with some form of orchestration, Docker swarm or Kubernetes.
The credentials are mainly stored in a .env file at the moment and could
be added to the secrets but I need for people who are admins for a
particular cloud to add their cloud details to the app and then store their
credentials securely.
Unfortunately this will need a dynamic storage mechanism which i don't know how to do yet
Regards
Lance
Hi,
It can depend on which deployment option you plan to use for the application.
For instance, a Docker deployment orchestrated by Kubernetes gives the
option of using secrets for sensitive information, which a hoster such as
GCP manages conveniently. In this kind of deployment, configuration (and
secrets) are passed to the app as environment variables, on which
Kubernetes configuration maps and secrets are mapped to. Thanks to this,
values are stored nowhere in the app code, companion files or database.
Regards
Eric
------------------------------
*Sent:* Sunday, November 11, 2018 11:07:14 PM
*Subject:* Re: How do I store details securely with django?

I agree credentials should not be stored in the database but what are
your other assumptions about the threats?
How many sets of credentials will there be?
In future, will you be using simple credentials or tokens, certificates,
multi factor auth?
If this is a prototype and only a few sets are involved you can store
credentials in a file or one file per set and write a method to fetch
them as required. That will keep them out of the database and let you
rejig the method after you have decided how it should really work.

Post by Lance Haig
Does anyone have suggestions on how I can accomplish this?
I would really appreciate some advice.
Regards
Lance

--
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/CANwgZcad67wDNhuAp7SBpdNY0T%2BSHCxQEvZ8nOf7Gge0Ndv6bA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Lance Haig

2018-11-12 15:45:50 UTC

Permalink

Hi Eric,

I am sure I have not explained myself properly.

The app does the following.

It presents a user the ability to sign up to a cloud platform for a
sandbox / playground account.
The number of cloud services that are available will change over time.

Each cloud platform has a set of credentials (username, password, domain
etc...) These credentials will have elevated permissions within their
own environments and so should be kept as safe as possible.

Currently I use secrets and .env files to provide these credentials.
This requires physical access to the platform to add new secrets etc...

I want to enable editing (e.g. CRUD on the platform credentials) without
having to redeploy the application or update the secrets.
The idea was to enable an admin interface to the DB so that each cloud
platform admin could add more or delete their platform from the solution.
This requires a place to store secrets that can be updated deleted and
created.
I was hoping that there might be a standard way to store these that is
secure other than adding secrets or updating the .env file.

Thanks for trying to understand my vague question.

Lance

Post by PASCUAL Eric
Hi Lance,
Â but I need for people who are admins for a particular cloud to add
their cloud details to the app and then store their credentials securely.
I'm not sure to understand the need for adding cloud details to the app for the admins.
The suggestion I made assumed that sensitive information is managed as
K8S secrets. As long as the admins have GCloud (for instance)
credentials set (which are stored and managed at GCloud level), they
can administrate the secrets resources by "applying" the corresponding
YAML descriptors remotely from their workstation. The sensitive values
are thus stored nowhere inside the application itself, but passed to
the containers at runtime as environment variables.
Maybe I've misunderstood your need and sorry in this case if my answer is off topic.
Best
Eric
------------------------------------------------------------------------
*Sent:* Monday, November 12, 2018 9:07:30 AM
*Subject:* Re: How do I store details securely with django?
Hi Eric,
Thanks for the response.
This idea has an end goal of being deployed in a resilient way so most
probably docker with some form of orchestration, Docker swarm or Kubernetes.
The credentials are mainly stored in a .env file at the moment and
could be added to the secrets but I need for people who are admins for
a particular cloud to add their cloud details to the app and then
store their credentials securely.
Unfortunately this will need a dynamic storage mechanism which i don't know how to do yet
Regards
Lance

Post by PASCUAL Eric
Hi,
It can depend on which deployment option you plan to use for the application.
For instance,Â a Docker deployment orchestrated by Kubernetes gives
the option of using secrets for sensitive information, which a hoster
such as GCP manages conveniently. In this kind of deployment,
configuration (and secrets) are passed to the app as environment
variables, on which Kubernetes configuration maps and secrets are
mapped to. Thanks to this, values are stored nowhere in the app code,
companion files or database.
Regards
Eric
------------------------------------------------------------------------
*Sent:* Sunday, November 11, 2018 11:07:14 PM
*Subject:* Re: How do I store details securely with django?

I agree credentials should not be stored in the database but what are
your other assumptions about the threats?
How many sets of credentials will there be?
In future, will you be using simple credentials or tokens, certificates,
multi factor auth?
If this is a prototype and only a few sets are involved you can store
credentials in a file or one file per set and write a method to fetch
them as required. That will keep them out of the database and let you
rejig the method after you have decided how it should really work.

Post by Lance Haig
Does anyone have suggestions on how I can accomplish this?
I would really appreciate some advice.
Regards
Lance

--
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
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/478ff804-4204-54c2-ba62-c0e4f9d64f89%40gmail.com
<https://groups.google.com/d/msgid/django-users/478ff804-4204-54c2-ba62-c0e4f9d64f89%40gmail.com?utm_medium=email&utm_source=footer>.
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
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/VI1P193MB0432916809AFE450553011D98CC10%40VI1P193MB0432.EURP193.PROD.OUTLOOK.COM
<https://groups.google.com/d/msgid/django-users/VI1P193MB0432916809AFE450553011D98CC10%40VI1P193MB0432.EURP193.PROD.OUTLOOK.COM?utm_medium=email&utm_source=footer>.
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.
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/88270da4-395f-90ff-77ce-b1639b2d39d5%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

PASCUAL Eric

2018-11-12 22:35:42 UTC

Permalink

Hi Lance,

Well, I was off topic. Sorry for this :/ I understand your need better now.

There are chances you've already thought to this option, but what about storing the sensitive data encrypted with a key based on a passphrase the user must provide when logging, in addition to the usual credentials ? This passphrase would not be stored anywhere, so even if the DB is compromised, the sensitive data would not be usable.

Eric

________________________________
From: django-***@googlegroups.com <django-***@googlegroups.com> on behalf of Lance Haig <***@gmail.com>
Sent: Monday, November 12, 2018 4:45:50 PM
To: django-***@googlegroups.com
Subject: Re: How do I store details securely with django?

Hi Eric,

I am sure I have not explained myself properly.

The app does the following.

It presents a user the ability to sign up to a cloud platform for a sandbox / playground account.
The number of cloud services that are available will change over time.

Each cloud platform has a set of credentials (username, password, domain etc...) These credentials will have elevated permissions within their own environments and so should be kept as safe as possible.

Currently I use secrets and .env files to provide these credentials.
This requires physical access to the platform to add new secrets etc...

I want to enable editing (e.g. CRUD on the platform credentials) without having to redeploy the application or update the secrets.
The idea was to enable an admin interface to the DB so that each cloud platform admin could add more or delete their platform from the solution.
This requires a place to store secrets that can be updated deleted and created.
I was hoping that there might be a standard way to store these that is secure other than adding secrets or updating the .env file.

Thanks for trying to understand my vague question.

Lance

On 11/12/18 10:04 AM, PASCUAL Eric wrote:

Hi Lance,

but I need for people who are admins for a particular cloud to add their cloud details to the app and then store their credentials securely.

I'm not sure to understand the need for adding cloud details to the app for the admins.

The suggestion I made assumed that sensitive information is managed as K8S secrets. As long as the admins have GCloud (for instance) credentials set (which are stored and managed at GCloud level), they can administrate the secrets resources by "applying" the corresponding YAML descriptors remotely from their workstation. The sensitive values are thus stored nowhere inside the application itself, but passed to the containers at runtime as environment variables.

Maybe I've misunderstood your need and sorry in this case if my answer is off topic.

Best

Eric

________________________________
From: django-***@googlegroups.com<mailto:django-***@googlegroups.com> <django-***@googlegroups.com><mailto:django-***@googlegroups.com> on behalf of Lance Haig <***@gmail.com><mailto:***@gmail.com>
Sent: Monday, November 12, 2018 9:07:30 AM
To: django-***@googlegroups.com<mailto:django-***@googlegroups.com>
Subject: Re: How do I store details securely with django?

Hi Eric,

Thanks for the response.

This idea has an end goal of being deployed in a resilient way so most probably docker with some form of orchestration, Docker swarm or Kubernetes.

The credentials are mainly stored in a .env file at the moment and could be added to the secrets but I need for people who are admins for a particular cloud to add their cloud details to the app and then store their credentials securely.

Unfortunately this will need a dynamic storage mechanism which i don't know how to do yet

Regards

Lance

On 11/12/18 12:03 AM, PASCUAL Eric wrote:

Hi,

It can depend on which deployment option you plan to use for the application.

For instance, a Docker deployment orchestrated by Kubernetes gives the option of using secrets for sensitive information, which a hoster such as GCP manages conveniently. In this kind of deployment, configuration (and secrets) are passed to the app as environment variables, on which Kubernetes configuration maps and secrets are mapped to. Thanks to this, values are stored nowhere in the app code, companion files or database.

Regards

Eric

________________________________
From: django-***@googlegroups.com<mailto:django-***@googlegroups.com> <django-***@googlegroups.com><mailto:django-***@googlegroups.com> on behalf of Mike Dewhirst <***@dewhirst.com.au><mailto:***@dewhirst.com.au>
Sent: Sunday, November 11, 2018 11:07:14 PM
To: django-***@googlegroups.com<mailto:django-***@googlegroups.com>
Subject: Re: How do I store details securely with django?

Post by Lance Haig
Does anyone have suggestions on how I can accomplish this?
I would really appreciate some advice.
Regards
Lance

--
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>.
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/c8819341-7c60-56ee-6298-3a6a7897e9b1%40dewhirst.com.au.
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>.
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/VI1P193MB043243D0747282C2D96F60E38CC00%40VI1P193MB0432.EURP193.PROD.OUTLOOK.COM<https://groups.google.com/d/msgid/django-users/VI1P193MB043243D0747282C2D96F60E38CC00%40VI1P193MB0432.EURP193.PROD.OUTLOOK.COM?utm_medium=email&utm_source=footer>.
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>.
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/478ff804-4204-54c2-ba62-c0e4f9d64f89%40gmail.com<https://groups.google.com/d/msgid/django-users/478ff804-4204-54c2-ba62-c0e4f9d64f89%40gmail.com?utm_medium=email&utm_source=footer>.
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>.
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/VI1P193MB0432916809AFE450553011D98CC10%40VI1P193MB0432.EURP193.PROD.OUTLOOK.COM<https://groups.google.com/d/msgid/django-users/VI1P193MB0432916809AFE450553011D98CC10%40VI1P193MB0432.EURP193.PROD.OUTLOOK.COM?utm_medium=email&utm_source=footer>.
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>.
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/88270da4-395f-90ff-77ce-b1639b2d39d5%40gmail.com<https://groups.google.com/d/msgid/django-users/88270da4-395f-90ff-77ce-b1639b2d39d5%40gmail.com?utm_medium=email&utm_source=footer>.
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.
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/VI1P193MB04323838756D4FC42BD744728CC10%40VI1P193MB0432.EURP193.PROD.OUTLOOK.COM.
For more options, visit https://groups.google.com/d/optout.

Devender Kumar

2018-11-13 03:55:39 UTC

Permalink

Hi
Study about LDAP protocol
Regards
Dev

Post by PASCUAL Eric
Hi Lance,
Well, I was off topic. Sorry for this :/ I understand your need better now.
There are chances you've already thought to this option, but what about
storing the sensitive data encrypted with a key based on a passphrase the
user must provide when logging, in addition to the usual credentials ? This
passphrase would not be stored anywhere, so even if the DB is compromised,
the sensitive data would not be usable.
Eric
------------------------------
*Sent:* Monday, November 12, 2018 4:45:50 PM
*Subject:* Re: How do I store details securely with django?
Hi Eric,
I am sure I have not explained myself properly.
The app does the following.
It presents a user the ability to sign up to a cloud platform for a
sandbox / playground account.
The number of cloud services that are available will change over time.
Each cloud platform has a set of credentials (username, password, domain
etc...) These credentials will have elevated permissions within their own
environments and so should be kept as safe as possible.
Currently I use secrets and .env files to provide these credentials.
This requires physical access to the platform to add new secrets etc...
I want to enable editing (e.g. CRUD on the platform credentials) without
having to redeploy the application or update the secrets.
The idea was to enable an admin interface to the DB so that each cloud
platform admin could add more or delete their platform from the solution.
This requires a place to store secrets that can be updated deleted and created.
I was hoping that there might be a standard way to store these that is
secure other than adding secrets or updating the .env file.
Thanks for trying to understand my vague question.
Lance
Hi Lance,
but I need for people who are admins for a particular cloud to add their
cloud details to the app and then store their credentials securely.
I'm not sure to understand the need for adding cloud details to the app for the admins.
The suggestion I made assumed that sensitive information is managed as K8S
secrets. As long as the admins have GCloud (for instance) credentials set
(which are stored and managed at GCloud level), they can administrate the
secrets resources by "applying" the corresponding YAML descriptors
remotely from their workstation. The sensitive values are thus stored
nowhere inside the application itself, but passed to the containers at
runtime as environment variables.
Maybe I've misunderstood your need and sorry in this case if my answer is off topic.
Best
Eric
------------------------------
*Sent:* Monday, November 12, 2018 9:07:30 AM
*Subject:* Re: How do I store details securely with django?
Hi Eric,
Thanks for the response.
This idea has an end goal of being deployed in a resilient way so most
probably docker with some form of orchestration, Docker swarm or Kubernetes.
The credentials are mainly stored in a .env file at the moment and could
be added to the secrets but I need for people who are admins for a
particular cloud to add their cloud details to the app and then store their
credentials securely.
Unfortunately this will need a dynamic storage mechanism which i don't know how to do yet
Regards
Lance
Hi,
It can depend on which deployment option you plan to use for the application.
For instance, a Docker deployment orchestrated by Kubernetes gives the
option of using secrets for sensitive information, which a hoster such as
GCP manages conveniently. In this kind of deployment, configuration (and
secrets) are passed to the app as environment variables, on which
Kubernetes configuration maps and secrets are mapped to. Thanks to this,
values are stored nowhere in the app code, companion files or database.
Regards
Eric
------------------------------
*Sent:* Sunday, November 11, 2018 11:07:14 PM
*Subject:* Re: How do I store details securely with django?

I agree credentials should not be stored in the database but what are
your other assumptions about the threats?
How many sets of credentials will there be?
In future, will you be using simple credentials or tokens, certificates,
multi factor auth?
If this is a prototype and only a few sets are involved you can store
credentials in a file or one file per set and write a method to fetch
them as required. That will keep them out of the database and let you
rejig the method after you have decided how it should really work.

Post by Lance Haig
Does anyone have suggestions on how I can accomplish this?
I would really appreciate some advice.
Regards
Lance

--
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
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/c8819341-7c60-56ee-6298-3a6a7897e9b1%40dewhirst.com.au
.
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
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/VI1P193MB043243D0747282C2D96F60E38CC00%40VI1P193MB0432.EURP193.PROD.OUTLOOK.COM
<https://groups.google.com/d/msgid/django-users/VI1P193MB043243D0747282C2D96F60E38CC00%40VI1P193MB0432.EURP193.PROD.OUTLOOK.COM?utm_medium=email&utm_source=footer>
.
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
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/478ff804-4204-54c2-ba62-c0e4f9d64f89%40gmail.com
<https://groups.google.com/d/msgid/django-users/478ff804-4204-54c2-ba62-c0e4f9d64f89%40gmail.com?utm_medium=email&utm_source=footer>
.
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
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/VI1P193MB0432916809AFE450553011D98CC10%40VI1P193MB0432.EURP193.PROD.OUTLOOK.COM
<https://groups.google.com/d/msgid/django-users/VI1P193MB0432916809AFE450553011D98CC10%40VI1P193MB0432.EURP193.PROD.OUTLOOK.COM?utm_medium=email&utm_source=footer>
.
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
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/88270da4-395f-90ff-77ce-b1639b2d39d5%40gmail.com
<https://groups.google.com/d/msgid/django-users/88270da4-395f-90ff-77ce-b1639b2d39d5%40gmail.com?utm_medium=email&utm_source=footer>
.
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
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/VI1P193MB04323838756D4FC42BD744728CC10%40VI1P193MB0432.EURP193.PROD.OUTLOOK.COM
<https://groups.google.com/d/msgid/django-users/VI1P193MB04323838756D4FC42BD744728CC10%40VI1P193MB0432.EURP193.PROD.OUTLOOK.COM?utm_medium=email&utm_source=footer>
.
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.
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/CALZ%3DbEKYs7TkjPPbSfB5ogXyGUbswgRkju8%3DitEgu_%2B9cSRD-A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Lance Haig

2018-11-14 15:01:29 UTC

Permalink

Hi Dev,

I believe that it would not provide much more security around the details.

Thank you for responding.

Regards

Lance

Post by Devender Kumar
Hi
Study about LDAP protocol
Regards
Dev
Hi Lance,
Well, I was off topic. Sorry for this :/ I understand your need better now.
There are chances you've already thought to this option, but what
about storing the sensitive data encrypted with a key based on a
passphrase the user must provide when logging, in addition to the
usual credentials ? This passphrase would not be stored anywhere,
so even if the DB is compromised, the sensitive data would not be
usable.
Eric
------------------------------------------------------------------------
*Sent:* Monday, November 12, 2018 4:45:50 PM
*Subject:* Re: How do I store details securely with django?
Hi Eric,
I am sure I have not explained myself properly.
The app does the following.
It presents a user the ability to sign up to a cloud platform for
a sandbox / playground account.
The number of cloud services that are available will change over time.
Each cloud platform has a set of credentials (username, password,
domain etc...) These credentials will have elevated permissions
within their own environments and so should be kept as safe as
possible.
Currently I use secrets and .env files to provide these credentials.
This requires physical access to the platform to add new secrets etc...
I want to enable editing (e.g. CRUD on the platform credentials)
without having to redeploy the application or update the secrets.
The idea was to enable an admin interface to the DB so that each
cloud platform admin could add more or delete their platform from
the solution.
This requires a place to store secrets that can be updated deleted and created.
I was hoping that there might be a standard way to store these
that is secure other than adding secrets or updating the .env file.
Thanks for trying to understand my vague question.
Lance

Post by PASCUAL Eric
Hi Lance,
Â but I need for people who are admins for a particular cloud to
add their cloud details to the app and then store their
credentials securely.
I'm not sure to understand the need for adding cloud details to
the app for the admins.
The suggestion I made assumed that sensitive information is
managed as K8S secrets. As long as the admins have GCloud (for
instance) credentials set (which are stored and managed at GCloud
level), they can administrate the secrets resources by "applying"
the corresponding YAML descriptors remotely from their
workstation. The sensitive values are thus stored nowhere inside
the application itself, but passed to the containers at runtime
as environment variables.
Maybe I've misunderstood your need and sorry in this case if my
answer is off topic.
Best
Eric
------------------------------------------------------------------------
*Sent:* Monday, November 12, 2018 9:07:30 AM
*Subject:* Re: How do I store details securely with django?
Hi Eric,
Thanks for the response.
This idea has an end goal of being deployed in a resilient way so
most probably docker with some form of orchestration, Docker
swarm or Kubernetes.
The credentials are mainly stored in a .env file at the moment
and could be added to the secrets but I need for people who are
admins for a particular cloud to add their cloud details to the
app and then store their credentials securely.
Unfortunately this will need a dynamic storage mechanism which i
don't know how to do yet
Regards
Lance

Post by PASCUAL Eric
Hi,
It can depend on which deployment option you plan to use for the application.
For instance,Â a Docker deployment orchestrated by Kubernetes
gives the option of using secrets for sensitive information,
which a hoster such as GCP manages conveniently. In this kind of
deployment, configuration (and secrets) are passed to the app as
environment variables, on which Kubernetes configuration maps
and secrets are mapped to. Thanks to this, values are stored
nowhere in the app code, companion files or database.
Regards
Eric
------------------------------------------------------------------------
*Sent:* Sunday, November 11, 2018 11:07:14 PM
*Subject:* Re: How do I store details securely with django?

Post by Lance Haig
Hi,
I have a project I am working on

https://github.com/lhaig/usery/ and

Post by Lance Haig
part of the roadmap of the project is to add more cloud types

to the

Post by Lance Haig
list.
I wanted to allow admins for these services to login and create
records for their different clouds in the DB and then use

these when

Post by Lance Haig
people request access to these services.
I need to find a secure way to store these credentials so that

even if

Post by Lance Haig
the DB is compromised that the credentials are safe.

I agree credentials should not be stored in the database but what are
your other assumptions about the threats?
How many sets of credentials will there be?
In future, will you be using simple credentials or tokens, certificates,
multi factor auth?
If this is a prototype and only a few sets are involved you can store
credentials in a file or one file per set and write a method to fetch
them as required. That will keep them out of the database and let you
rejig the method after you have decided how it should really work.

Post by Lance Haig
Does anyone have suggestions on how I can accomplish this?
I would really appreciate some advice.
Regards
Lance

--
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
To post to this group, send email to
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/c8819341-7c60-56ee-6298-3a6a7897e9b1%40dewhirst.com.au.
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
To post to this group, send email to
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/VI1P193MB043243D0747282C2D96F60E38CC00%40VI1P193MB0432.EURP193.PROD.OUTLOOK.COM
<https://groups.google.com/d/msgid/django-users/VI1P193MB043243D0747282C2D96F60E38CC00%40VI1P193MB0432.EURP193.PROD.OUTLOOK.COM?utm_medium=email&utm_source=footer>.
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,
To post to this group, send email to
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/478ff804-4204-54c2-ba62-c0e4f9d64f89%40gmail.com
<https://groups.google.com/d/msgid/django-users/478ff804-4204-54c2-ba62-c0e4f9d64f89%40gmail.com?utm_medium=email&utm_source=footer>.
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,
To post to this group, send email to
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/VI1P193MB0432916809AFE450553011D98CC10%40VI1P193MB0432.EURP193.PROD.OUTLOOK.COM
<https://groups.google.com/d/msgid/django-users/VI1P193MB0432916809AFE450553011D98CC10%40VI1P193MB0432.EURP193.PROD.OUTLOOK.COM?utm_medium=email&utm_source=footer>.
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,
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/88270da4-395f-90ff-77ce-b1639b2d39d5%40gmail.com
<https://groups.google.com/d/msgid/django-users/88270da4-395f-90ff-77ce-b1639b2d39d5%40gmail.com?utm_medium=email&utm_source=footer>.
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,
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/VI1P193MB04323838756D4FC42BD744728CC10%40VI1P193MB0432.EURP193.PROD.OUTLOOK.COM
<https://groups.google.com/d/msgid/django-users/VI1P193MB04323838756D4FC42BD744728CC10%40VI1P193MB0432.EURP193.PROD.OUTLOOK.COM?utm_medium=email&utm_source=footer>.
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
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/CALZ%3DbEKYs7TkjPPbSfB5ogXyGUbswgRkju8%3DitEgu_%2B9cSRD-A%40mail.gmail.com
<https://groups.google.com/d/msgid/django-users/CALZ%3DbEKYs7TkjPPbSfB5ogXyGUbswgRkju8%3DitEgu_%2B9cSRD-A%40mail.gmail.com?utm_medium=email&utm_source=footer>.
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.
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/acc80bb1-6528-d7b3-ce4b-9208e91ca988%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Lance Haig

2018-11-14 15:00:14 UTC

Permalink

Thanks Eric,

I did not explain myself properly so the mistake was mine.

Thanks for the help.

Lance

Post by PASCUAL Eric
Hi Lance,
Â but I need for people who are admins for a particular cloud to add
their cloud details to the app and then store their credentials securely.
I'm not sure to understand the need for adding cloud details to the app for the admins.
The suggestion I made assumed that sensitive information is managed
as K8S secrets. As long as the admins have GCloud (for instance)
credentials set (which are stored and managed at GCloud level), they
can administrate the secrets resources by "applying" the
corresponding YAML descriptors remotely from their workstation. The
sensitive values are thus stored nowhere inside the application
itself, but passed to the containers at runtime as environment variables.
Maybe I've misunderstood your need and sorry in this case if my answer is off topic.
Best
Eric
------------------------------------------------------------------------
*Sent:* Monday, November 12, 2018 9:07:30 AM
*Subject:* Re: How do I store details securely with django?
Hi Eric,
Thanks for the response.
This idea has an end goal of being deployed in a resilient way so
most probably docker with some form of orchestration, Docker swarm or
Kubernetes.
The credentials are mainly stored in a .env file at the moment and
could be added to the secrets but I need for people who are admins
for a particular cloud to add their cloud details to the app and then
store their credentials securely.
Unfortunately this will need a dynamic storage mechanism which i don't know how to do yet
Regards
Lance

Post by PASCUAL Eric
Hi,
It can depend on which deployment option you plan to use for the application.
For instance,Â a Docker deployment orchestrated by Kubernetes gives
the option of using secrets for sensitive information, which a
hoster such as GCP manages conveniently. In this kind of deployment,
configuration (and secrets) are passed to the app as environment
variables, on which Kubernetes configuration maps and secrets are
mapped to. Thanks to this, values are stored nowhere in the app
code, companion files or database.
Regards
Eric
------------------------------------------------------------------------
*Sent:* Sunday, November 11, 2018 11:07:14 PM
*Subject:* Re: How do I store details securely with django?

even if

Post by Lance Haig
the DB is compromised that the credentials are safe.

I agree credentials should not be stored in the database but what are
your other assumptions about the threats?
How many sets of credentials will there be?
In future, will you be using simple credentials or tokens,
certificates,
multi factor auth?
If this is a prototype and only a few sets are involved you can store
credentials in a file or one file per set and write a method to fetch
them as required. That will keep them out of the database and let you
rejig the method after you have decided how it should really work.

Post by Lance Haig
Does anyone have suggestions on how I can accomplish this?
I would really appreciate some advice.
Regards
Lance

--
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
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/88270da4-395f-90ff-77ce-b1639b2d39d5%40gmail.com
<https://groups.google.com/d/msgid/django-users/88270da4-395f-90ff-77ce-b1639b2d39d5%40gmail.com?utm_medium=email&utm_source=footer>.
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
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/VI1P193MB04323838756D4FC42BD744728CC10%40VI1P193MB0432.EURP193.PROD.OUTLOOK.COM
<https://groups.google.com/d/msgid/django-users/VI1P193MB04323838756D4FC42BD744728CC10%40VI1P193MB0432.EURP193.PROD.OUTLOOK.COM?utm_medium=email&utm_source=footer>.
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.
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/551861a4-8de5-0aba-3794-ccbbd559d77b%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Lance Haig

2018-11-12 08:02:58 UTC

Permalink

Hi,

Thanks for responding.

My answers inline

Post by Mike Dewhirst

Post by Lance Haig
Hi,
I have a project I am working on https://github.com/lhaig/usery/ and
part of the roadmap of the project is to add more cloud types to the list.
I wanted to allow admins for these services to login and create
records for their different clouds in the DB and then use these when
people request access to these services.
I need to find a secure way to store these credentials so that even
if the DB is compromised that the credentials are safe.

I agree credentials should not be stored in the database but what are
your other assumptions about the threats?
How many sets of credentials will there be?

it could potentially be 5 to 10 per admin account

Post by Mike Dewhirst
In future, will you be using simple credentials or tokens,
certificates, multi factor auth?

These credentials are access details to other clouds.

The application is a user sandbox portal to allow admins to grant X
number of days access to a cloud for testing and discovery.

It currently is focused on openstack but he roadmap plan is to add
docker Kubernetes etc..

So I need to have the ability for the cloud admins to add or remove
authentication details as they are needed.

Post by Mike Dewhirst
If this is a prototype and only a few sets are involved you can store
credentials in a file or one file per set and write a method to fetch
them as required. That will keep them out of the database and let you
rejig the method after you have decided how it should really work.

I currently use the .env file to hold these credentials but that does
not scale very well when you need to add more and more.

Post by Mike Dewhirst

Post by Lance Haig
Does anyone have suggestions on how I can accomplish this?
I would really appreciate some advice.
Regards
Lance

--
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/9fa91ea9-58dc-bbc6-4e3c-e4142170cc7b%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Mike Dewhirst

2018-11-12 08:30:47 UTC

Permalink

Post by Lance Haig
Hi,
Thanks for responding.
My answers inline

Post by Mike Dewhirst

Post by Lance Haig
Hi,
I have a project I am working on https://github.com/lhaig/usery/ and
part of the roadmap of the project is to add more cloud types to the list.
I wanted to allow admins for these services to login and create
records for their different clouds in the DB and then use these when
people request access to these services.
I need to find a secure way to store these credentials so that even
if the DB is compromised that the credentials are safe.

I agree credentials should not be stored in the database but what are
your other assumptions about the threats?
How many sets of credentials will there be?

it could potentially be 5 to 10 per admin account

Post by Mike Dewhirst
In future, will you be using simple credentials or tokens,
certificates, multi factor auth?

These credentials are access details to other clouds.
The application is a user sandbox portal to allow admins to grant X
number of days access to a cloud for testing and discovery.
It currently is focused on openstack but he roadmap plan is to add
docker Kubernetes etc..
So I need to have the ability for the cloud admins to add or remove
authentication details as they are needed.

I haven't thought deeply about this because it is not my project but on
the surface, if they are temporary credentials I cannot see much need
for heavy duty security.

If the perceived risk is database compromise it might be better to
configure the database or the database server with an ACL including only
the Django server IP address and perhaps one or two trusted people.

Maybe Kubernetes secrets is the eventual way forward but scalability is
assured if you can keep the creds in the database.

What about a separate non-public schema (assuming Postgres) for creds?
I'm sure you could lock that down to particular permission groups which
ought keep things secure enough.

The bottom line question: What is lost if temporary creds are compromised?

Risk is hazard multiplied by likelihood/opportunity

If you can reduce either side of that equation you reduce risk.

What plan do you have to execute to recover from the feared event
when/if it happens?

When all things are considered the answer to that last question
determines how much effort is warranted.

Post by Lance Haig

I currently use the .env file to hold these credentials but that does
not scale very well when you need to add more and more.

Post by Mike Dewhirst

Post by Lance Haig
Does anyone have suggestions on how I can accomplish this?
I would really appreciate some advice.
Regards
Lance

--
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/e6bb90c6-3f28-b190-d631-3f7b20fd2f99%40dewhirst.com.au.
For more options, visit https://groups.google.com/d/optout.

Lance Haig

2018-11-12 15:52:46 UTC

Permalink

Hi Mike,

Thank you for taking the time to read this.

I have highlighted these sentences in your response

*The bottom line question: What is lost if temporary creds are
compromised?*

The credentials have high level access to the backed system think e.gÂ
kubernetes admin so compromise would mean full access to kubernetes to
add remove delete anything.

*What plan do you have to execute to recover from the feared event
when/if it happens?*

This is a valid question, The recovery for these would be rebuild of a
cluster or service. depending on the damage caused.

It seems my idea of making these options configurable via a web UI will
not easily be done.

I will have to stay with the current deployment plan.

Thanks

Lance

Post by Mike Dewhirst

Post by Lance Haig
Hi,
Thanks for responding.
My answers inline

Post by Mike Dewhirst

Post by Lance Haig
Hi,
I have a project I am working on https://github.com/lhaig/usery/
and part of the roadmap of the project is to add more cloud types
to the list.
I wanted to allow admins for these services to login and create
records for their different clouds in the DB and then use these
when people request access to these services.
I need to find a secure way to store these credentials so that even
if the DB is compromised that the credentials are safe.

I agree credentials should not be stored in the database but what
are your other assumptions about the threats?
How many sets of credentials will there be?

it could potentially be 5 to 10 per admin account

Post by Mike Dewhirst
In future, will you be using simple credentials or tokens,
certificates, multi factor auth?

These credentials are access details to other clouds.
The application is a user sandbox portal to allow admins to grant X
number of days access to a cloud for testing and discovery.
It currently is focused on openstack but he roadmap plan is to add
docker Kubernetes etc..
So I need to have the ability for the cloud admins to add or remove
authentication details as they are needed.

I haven't thought deeply about this because it is not my project but
on the surface, if they are temporary credentials I cannot see much
need for heavy duty security.
If the perceived risk is database compromise it might be better to
configure the database or the database server with an ACL including
only the Django server IP address and perhaps one or two trusted people.
Maybe Kubernetes secrets is the eventual way forward but scalability
is assured if you can keep the creds in the database.
What about a separate non-public schema (assuming Postgres) for creds?
I'm sure you could lock that down to particular permission groups
which ought keep things secure enough.
The bottom line question: What is lost if temporary creds are
compromised?
Risk is hazard multiplied by likelihood/opportunity
If you can reduce either side of that equation you reduce risk.
What plan do you have to execute to recover from the feared event
when/if it happens?
When all things are considered the answer to that last question
determines how much effort is warranted.

Post by Lance Haig

Post by Mike Dewhirst
If this is a prototype and only a few sets are involved you can
store credentials in a file or one file per set and write a method
to fetch them as required. That will keep them out of the database
and let you rejig the method after you have decided how it should
really work.

I currently use the .env file to hold these credentials but that does
not scale very well when you need to add more and more.

Post by Mike Dewhirst

Post by Lance Haig
Does anyone have suggestions on how I can accomplish this?
I would really appreciate some advice.
Regards
Lance

--
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/d96ad464-ae03-59ad-0227-ff0feb9a177d%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Mike Dewhirst

2018-11-13 05:29:02 UTC

Permalink

Another thought

Django admin has a built-in mechanism for password management. It includes
forms with password widgets.Perhaps you could hack your own encryption of
the cloud credentials based on the Django approach to passwords.

It is possible to add forms to the Admin and include your own logic. I have
done that - without the extra credentials part - to create additional data
based on converting a @domain added to a username into a company name and
company profile.

Mike

Post by Lance Haig
Hi,
I have a project I am working on https://github.com/lhaig/usery/ and
part of the roadmap of the project is to add more cloud types to the list.
I wanted to allow admins for these services to login and create records
for their different clouds in the DB and then use these when people
request access to these services.
I need to find a secure way to store these credentials so that even if
the DB is compromised that the credentials are safe.
Does anyone have suggestions on how I can accomplish this?
I would really appreciate some advice.
Regards
Lance

--
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/df4e7fc2-cf4d-4742-9fd3-adc1e7d037c6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Lance Haig

2018-11-14 14:59:19 UTC

Permalink

Thanks I will take a look at that

Lance

Post by Mike Dewhirst
Another thought
Django admin has a built-in mechanism for password management. It
includes forms with password widgets.Perhaps you could hack your own
encryption of the cloud credentials based on the Django approach to
passwords.
It is possible to add forms to the Admin and include your own logic. I
have done that - without the extra credentials part - to create
a company name and company profile.
Mike
Hi,
I have a project I am working on https://github.com/lhaig/usery/
<https://github.com/lhaig/usery/> and
part of the roadmap of the project is to add more cloud types to the list.
I wanted to allow admins for these services to login and create records
for their different clouds in the DB and then use these when people
request access to these services.
I need to find a secure way to store these credentials so that even if
the DB is compromised that the credentials are safe.
Does anyone have suggestions on how I can accomplish this?
I would really appreciate some advice.
Regards
Lance
--
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
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/df4e7fc2-cf4d-4742-9fd3-adc1e7d037c6%40googlegroups.com
<https://groups.google.com/d/msgid/django-users/df4e7fc2-cf4d-4742-9fd3-adc1e7d037c6%40googlegroups.com?utm_medium=email&utm_source=footer>.
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.
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/6a2b4ee0-8948-67e4-51b8-87bf3d268056%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Continue reading on narkive:

Search results for 'How do I store details securely with django?' (Questions and Answers)

replies

which language is better for dynamic webpages?

started 2012-12-18 01:30:59 UTC

programming & design