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
On 11/12/18 9:30 AM, Mike Dewhirst wrote:
On 12/11/2018 7:02 PM, Lance Haig wrote:
Hi,
Thanks for responding.
My answers inline
On 11/11/18 11:07 PM, Mike Dewhirst wrote:
On 12/11/2018 12:47 AM, Lance Haig wrote:
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
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.
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.
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+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@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.
