Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Kubernetes-secret operator #336

Open
LucasSegersFabro opened this issue Mar 19, 2024 · 3 comments
Open

Kubernetes-secret operator #336

LucasSegersFabro opened this issue Mar 19, 2024 · 3 comments

Comments

@LucasSegersFabro
Copy link

Hey!

I love dot-env vault and I was wondering if there are any considerations for an auto sync solution for a kubernetes cluster.

Main use case:

  1. I manage my secrets with dotenv vault for many different applications and environments
  2. These applications run on a kubernetes cluster
  3. I'd like to keep any changes to a specific vault in sync with my cluster secrets and auto update my deployments

Something like external-secrets controller that has a well-stabilished API and implementations for different providers

Probably the controller would have to poll each configured secret for changes and pull them if needed, so maybe it's not something you'd want to enable for everyone at the same time (even though I guess that the majority of calls would be polling for the latest version)

Thanks :)

@motdotla
Copy link
Member

motdotla commented Mar 19, 2024

hi @LucasSegersFabro, we're considering it (others have requested it as well) but I also have some philosophical misgivings at the moment. Currently my raw thoughts are this:

  1. The .env.vault is a great mechanism to securely pass secrets on any platform, framework, or infrastructure. afterall, it's just a file. so anywhere you can move files (which is everywhere), you can move your .env.vault file
  2. Because .env.vault is just a file format standard, it can be implemented with any infra tool, etc in an agnostic way. it uses open cryptography standards.

essentially, I'm currently hesitant to get into the kubernetes external secrets controller because I see it mainly as a mechanism to interact with non-open non-agnostic vaulting systems.

what if you just shipped your .env.vault file with your code on kube? and just set a single DOTENV_KEY env/secret in kube?

welcome all thoughts here. my thoughts are developing here and I really do not know kube well.

@LucasSegersFabro
Copy link
Author

hey @motdotla , I completely understand

maybe you'd want a plug and play controller for a "premium tier", since it would poll from your servers if customers want it really hard

as for me things would work fine if I use the versioned file as the source of truth (given that we always remember to pull/commit it).
it would be easier still since we git-opts everything into the cluster

the only hassle would be that I'd need an environment with nodejs to use the cli (and decrypt the file). Maybe if it was shipped with static-linked binaries (like with golang) this would be a non-issue

feel free to close the issue if needed, since I can easily work around it
also feel free to reach out if you need any pointers with kube :)

@motdotla
Copy link
Member

Maybe if it was shipped with static-linked binaries (like with golang) this would be a non-issue

yeah, dotenvx is/has solved that problem.

increasingly, moving development efforts towards it and probably will coalesce dotenv-vault towards it as well

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants