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

[FEAT] Import secrets as .env files and export in environment #437

Open
saheljalal opened this issue Mar 5, 2023 · 2 comments
Open

[FEAT] Import secrets as .env files and export in environment #437

saheljalal opened this issue Mar 5, 2023 · 2 comments
Labels
enhancement New feature or request

Comments

@saheljalal
Copy link

saheljalal commented Mar 5, 2023

Is your feature request related to a problem? Please describe.
Yes, for every project's CI now I need to explicitly indicate every env var I need exported so that builds and deployments work. But this becomes tedious and prevents the ability to build projects from templates easily.

Describe the solution you'd like
It's common to use .env, .env.stg, .env.prd etc. files in local development and deploying. I'm using Vault to store the contents of these files entirely and in deployments I'm reading the same files and writing it out as a .env file which is sourced in deployment before executing a workload. It would be great if this action had some sort of mechanism to make this simpler and provide a purpose driven way where it recognizes the use case.

Describe alternatives you've considered
Similar requests appear to made with #336, #234, and #153 but none describe using entire content values as .env files which might be easier to deal with than parsing key/value pairs on all downstream uses like K8s deployments.

Additional context
The CI workflow for a single service I'm using includes provisioning infrastructure, writing out secrets (db names/pws etc.) to Vault, reading them in GHA, building and deploying with them as env vars, and finally injecting them in K8s deployments which source the same env vars from Vault. Not sure if optimal but trying to figure out the best way to make everything automated E2E and secure.

@saheljalal saheljalal added the enhancement New feature or request label Mar 5, 2023
@Elio-FairlyMade
Copy link

I would also love to see this feature implemented instead of relying of my users scripts 👍

@nawanglama-krispcall
Copy link

we are waiting for this fix.

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

No branches or pull requests

3 participants