Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
Yes.
The problem is effectively secrets management as a whole, recent work on #34 has shown a few shortcomings of simple .env files when combined with docker, in that maintainers probably aren't interested in managing multiple individual env files spread across a variety of directories. Effectively, the problem is secrets sprawl.
Describe the solution you'd like
A clear and concise description of what you want to happen.
Ideally, secrets would be set in a single location, which would provide an easy and single interface for accessing those secrets, this would enable various services/projects/apps within the Opensorcery stack, to access the secrets in one way, regardless of the service itself, it would be agnostic.
Ideally, this could be done with something like Hashicorp Vault, or utilising something akin to inotify where in the event that the base .env file is edited in the root dir, it pushes the env file into the relevant sub directories, allowing the dockerfile to sweep it in when it builds the image and creates the required volumes.
Is your feature request related to a problem? Please describe. A clear and concise description of what the problem is. Ex. I'm always frustrated when [...] Yes.
The problem is effectively secrets management as a whole, recent work on #34 has shown a few shortcomings of simple .env files when combined with docker, in that maintainers probably aren't interested in managing multiple individual env files spread across a variety of directories. Effectively, the problem is secrets sprawl.
Describe the solution you'd like A clear and concise description of what you want to happen. Ideally, secrets would be set in a single location, which would provide an easy and single interface for accessing those secrets, this would enable various services/projects/apps within the Opensorcery stack, to access the secrets in one way, regardless of the service itself, it would be agnostic.
Ideally, this could be done with something like Hashicorp Vault, or utilising something akin to
inotifywhere in the event that the base.envfile is edited in the root dir, it pushes the env file into the relevant sub directories, allowing the dockerfile to sweep it in when it builds the image and creates the required volumes.