Multiple config files - Githubissues

MatthieuCoder commented 3 years ago

Is your feature request related to a problem? Please describe.

I'm trying to run Hydra in Kubernetes using Vault as a DSN provider; for other containers i just change the startup script and load the environment variables using source, but the hydra container does not includes sh

Describe the solution you'd like

I'm thinking about multiple config files (like docker-compose does), so I can load another file from vault containing the secret

Describe alternatives you've considered

Loading secrets from files could be another solution, but this seems over complicated compared to the first solution

zepatrik commented 3 years ago

Can't you start the container with the env vars already set? That is the intended way of doing this.

MatthieuCoder commented 3 years ago

No, The vault-injector (vault-agent) only creates shared volumes using a init-container (and a sidecar for updating the file)

zepatrik commented 3 years ago

I see, maybe @Demonsthere or @piotrmsc know some workaround? Otherwise, I think there is no problem with supporting multiple config files, it is just a bit work to properly implement it.

zepatrik commented 3 years ago

Just looked into the code, it should already support multiple config files :thinking: Provide them with multiple hydra serve -c foo.yml -c bar.yml

MatthieuCoder commented 3 years ago

That's sweet! Should this be an option in the helm chart ?

zepatrik commented 3 years ago

Probably, if it is not yet possible.

MatthieuCoder commented 3 years ago

I'll look into that. I'll send a pr if it's not possible

MatthieuCoder commented 3 years ago

Actually, for it to work, I need to be able to disable the secret (or the DSN will be overwritten py the environment variable)

Demonsthere commented 3 years ago

Hi there, I think that actually the chart supports everything you might need for this to work:

Use custom secret for hydra
Mount additional config files as extraVolumes
The only thing that is missing is the expansion of arguments for the container but that shouldn't be hard to achieve.

If you can verify if the first 2 points are enough, I can patch the 3rd one quite easily ;)

MatthieuCoder commented 3 years ago

Hi! The first one does not work, the vault operator uses a sidecar container to create files on a shared volume between the two containers. The second solution may work using the vault csi provider, but we still need to configure hydra to load the file on the new volume (this might require to store the configuration file directly, so no compatibility with the vault system for managing database access)

The last solution might be enough considering we can already have the vault agent sidecar running with their mutating webhook, we could load an additional configuration file generated by the vault sidecar. The last thing i might need is to disable the secret generated by the chart, because as i understand it, it will override the configuration file (and the additional configuration file).

Thanks for your attention ;)

Demonsthere commented 3 years ago

I see. I guess the simples solution will be to port the same mechanism of optional secret as we have in keto

Edit: I was mistaken, changing the charts to not require the secret will be a bigger refactor than I first thought.

MatthieuCoder commented 3 years ago

I see... I'll use ExternalSecret then

github-actions[bot] commented 1 year ago

Hello contributors!

I am marking this issue as stale as it has not received any engagement from the community or maintainers for a year. That does not imply that the issue has no merit! If you feel strongly about this issue

open a PR referencing and resolving the issue;
leave a comment on it and discuss ideas on how you could contribute towards resolving it;
leave a comment and describe in detail why this issue is critical for your use case;
open a new issue with updated details and a plan for resolving the issue.

Throughout its lifetime, Ory has received over 10.000 issues and PRs. To sustain that growth, we need to prioritize and focus on issues that are important to the community. A good indication of importance, and thus priority, is activity on a topic.

Unfortunately, burnout has become a topic of concern amongst open-source projects.

It can lead to severe personal and health issues as well as opening catastrophic attack vectors.

The motivation for this automation is to help prioritize issues in the backlog and not ignore, reject, or belittle anyone.

If this issue was marked as stale erroneously you can exempt it by adding the backlog label, assigning someone, or setting a milestone for it.

Thank you for your understanding and to anyone who participated in the conversation! And as written above, please do participate in the conversation if this topic is important to you!

Thank you 🙏✌️

ory / k8s

Multiple config files #332