Hi everyone ! I am Shubham, from India, 3rd year undergrad in computer engineering
I am interested in the Secret Manager project idea. As far as I understood the project, it aims to implement popular Secret manager services like AWS and vault within django and to provide an interface over it ( i was thinking of something similar to, how django database configurations are implemented in django project settings) and also to implement a built-in support for per-environments settings option … is that correct ?
For the implementation part I was thinking of using something like environs alongside with the API services of the secret manager. Either Secret manager services could be used and configured or by default django could store secrets in an environment file which could be accessed by the appropriate services.
And once a environment file feature is implemented we can implement a design utilizing environment variables for per-environments settings.
Any suggestions are highly appreciated.
Thank you .
Hi Shubham - let me give you some of my thoughts on the project and how to propose the GSOC project!
The thing I want to see most is your proposed API design for the end user - I don’t mind what the implementation is behind the scenes (environs, secret manager APIs, etc) - the key thing we need to build and make sure is good, is the design of the API we give to people using Django, as that’s the thing that will be hardest to change later.
For example:
- How do you declare multiple environments and their different settings?
- How do you select an environment?
- How do you declare secret backends?
- How do you say a secret comes from a backend?
- How do these work with tests?
- What is the balance you want between duplication of settings versus small settings files? Can environments inherit/copy from each other?
Obviously some of the specific details would be worked out during a GSOC project, but we’d want to know that you had a good idea about how all of these interacted going in, so we could finish off the design and then get you writing the code.
3 Likes
Thank you very much Andrew for helping me out.
So my main takeaway is for the proposal I should put more emphasize on how the end user will interact with the system and workout the implementation around that.
I will try upload the first draft of my proposal soon.
Hi Shubham.
What Andrew said! 
For me, even if we take out things like Vault, one thing users struggle with is keeping secrets out of settings files. So if we had a good story (with a nice API) and how you store secrets (in say a file that gets loaded into the environment) without other dependencies then that’s a big win.
If then there’s also backends for Vault and the major cloud providers’ secret management solution then 
. But as long as the interface is defined, we wouldn’t even have to ship those. (Think django-redis and similar for caching…)
2 Likes
Hi Cartlon .
First of all, thanks for clarifying the points.
I just have a few doubts regarding the scope of this implementation. Taking points from how django cache works, we would also have to implement a default secret manager (for those who do not use any cloud solution) which would be a simple file based implementation, but as discussed here, it was not considered suitable to store secrets in a separate file. Should we take on a different approach regarding this implementation ?
And as for the per-environments settings, is it a good idea to restructure the project template into separate stages of dev and production which are then inherited by the settings.py, because this seems to be a backward compatible approach or should I look out for something else ? It would be of great help if someone can point me in right direction.
Thank you, for hearing me out
I’ll have a read of that thread but I think we should “pave the cow-paths” so to speak.
Folks are keeping secrets in a file, which they then read into their envs. That’s such a common approach that for us to say it’s not good enough is a little… well I’m not sure of the right word.
There may be better approaches, but that would be an acceptable, and simple enough, default option in my book.
C.
Update: I don’t think the suggestion in the thread is quite analogous to the .env file type approach I think we have in mind here…
Thanks Carlton, for solving my doubt.
I definitely agree it’s a good and simple enough approach just needed some confirmation with a more experienced developer.
Hello! This is the first time that I post here. I’m also interested in participate in this project in GSoC 2020. I was thinking some days about the solution of the problem and I got a conclusion similar to yours Shubham.
I was thinking in a service who connects with an API that will have the information about the secrets key, the connections with backends/secrets and who users can be use and modify this secrets. And files is needed to replace the information given by the service to put in settings file’s project. This project seems very interesting!
1 Like