#hashi-corp

app credentials_to_env

Fetch secrets from Hashicorp's Vault and write to environment or files, then exec another program

8 releases

Uses old Rust 2015

0.4.7 Sep 12, 2018
0.4.6 Aug 15, 2017
0.4.5 Jul 13, 2017
0.4.4 Nov 30, 2016
0.2.1 Mar 23, 2016

#13 in #hashi-corp

MIT/Apache

11KB
133 lines

credentials-to-env: Fetch secrets from Hashicorp's vault or elsewhere before execing a program

Latest version License Build Status

Static binary releases

Do you have a pre-existing program that assumes that it will receive secrets in either environment variables or files on disk? Would you like to convert that program to work with Hashicorp's Vault?

First run:

cargo install credentials_to_env

Then create a file named Secretfile explaining where in Vault the individual secrets can be found:

# Set environment variables based on Vault secrets.
DOCKER_HUB_USER secret/docker_hub:user
DOCKER_HUB_PASSWORD secret/docker_hub:password
DOCKER_HUB_EMAIL secret/docker_hub:email

# Create SSL key files based on Vault secrets.
>$HOME/.docker/ca.pem secret/docker:ca_pem
>$HOME/.docker/cert.pem secret/docker:cert_pem
>$HOME/.docker/key.pem secret/docker:key_pem

Finally, prefix the invocation of your program with credentials-to-env:

credentials-to-env myprogram arg1 arg2

This will automatically fetch secrets from Vault (or any other backend supported by credentials) and write them to the specified environment variables or files.

You can also override credentials-to-env by passing in the secrets yourself, which is handy if you call credentials-to-env inside a Docker container, but want to temporarily override the secrets you'd get from Vault.

Development notes

Pull requests are welcome! If you're not sure whether your idea would fit into the project's vision, please feel free to file an issue and ask us.

To build, you'll need to set up your OpenSSL paths first, as described by the Rust OpenSSL project.

To make an official release, you need to be a maintainer, and you need to have cargo publish permissions. If this is the case, first edit Cargo.toml to bump the version number, then regenerate Cargo.lock using:

cargo build

Commit the release, using a commit message of the format:

v<VERSION>: <SUMMARY>

<RELEASE NOTES>

Then run:

git tag v$VERSION
git push; git push --tags
cargo publish

This will rebuild the official binaries using Travis CI, and upload a new version of the crate to crates.io.

Dependencies

~17–27MB
~483K SLoC