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

Add support for encrypted environment variables #908

Closed
siliconcow opened this issue Feb 1, 2015 · 7 comments
Closed

Add support for encrypted environment variables #908

siliconcow opened this issue Feb 1, 2015 · 7 comments

Comments

@siliconcow
Copy link

Allow users to encrypt environmental variables in their yaml configuration so they can still feel comfortable keeping them in version control. Would decrypt values transparently with a chosen environmental variable (like FIG_CRYPT_KEY) and provide users a helper command to generate encrypted values.

Only downside is you have to add pycrypto as a dependency.

@danielwegener
Copy link

Would it really be useful to share a fig file that only you can use? Why don't you just use environment keys (see http://www.fig.sh/yml.html#environment) and export the secrets on your host environment in the first place? 👎

@cpuguy83
Copy link
Contributor

cpuguy83 commented Feb 4, 2015

Yes, this doesn't seem all that helpful.
You can even encrypt the values and decrypt once in the container.

@siliconcow
Copy link
Author

Other people on my team can use it, they just need to know the password. Environment files doesn't solve my problem of distributing secrets to my team members. I agree I can decrypt them in the container but then I need to do run-time munging of config files or write that facility into all my applications.

@pwaller
Copy link

pwaller commented Sep 4, 2015

At @scraperwiki we solve this using direnv and secret-tool which is a part of libsecret (part of libsecret-tools in debian).

That way, to get the secrets in your environment, you just cd to your project and unlock your keyring.

In your .envrc, you put this:

export SECRET=$(secret-tool lookup projectName SECRET)

You can equally well substitute secret-tool for a keyring manager of your choice.

@pwaller
Copy link

pwaller commented Sep 4, 2015

There is also #1534 which can possibly supersede this issue.

@dnephin
Copy link

dnephin commented Sep 4, 2015

Ya, I don't think compose should be responsible for any encryption or decryption (it's outside the scope of the problem compose is solving).

The above comments outline some good ways to handle this without compose being involved. env_file, environment keys with no values (so the value is read from the host), or environment variable interpolation in the config are all available to solve the problem.

@dnephin dnephin closed this as completed Sep 4, 2015
@pwaller
Copy link

pwaller commented Sep 4, 2015

moby/moby#13490 (still open for now) is also an eye opener. There are even some issues with using the environment for secrets that I wasn't aware of.

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

Successfully merging a pull request may close this issue.

5 participants