Managing credentials securely with end-to-end encryption utilities helps development teams to avoid embarrassing data leaks while sharing passwords among themselves or with deployment environments.
Unfortunately, keeping credentials separate from the application code that uses them can lead to both partition issues (keeping staging credentials separate from production ones) and discovery problems (knowing which credential to use when).
Today’s post won’t address all of the issues with credentials management, but it will help explain a specific utility that empowers developers to keep credentials and the code that uses them in the same place.
git-crypt is an open source, command line utility that empowers developers to protect specific files within a git repository.
Files which you choose to protect are encrypted when committed, and decrypted when checked out. git-crypt lets you freely share a repository containing a mix of public and private content. git-crypt gracefully degrades, so developers without the secret key can still clone and commit to a repository with encrypted files.
The advantage of using git-crypt is that your protected data stays alongside the code that uses it. You don’t need to configure or manage additional infrastructure (no AWS integration as with Credstash).
Unlike Credstash, there is no inherent versioning of credentials supported through git-crypt. Instead, versions are maintained through the very fact that all files in the repository are versioned natively.
DevOps Use Case
As mentioned above, the biggest advantage of git-crypt is that private data and public data can live in the same location. This means any developer can clone your repository, but only permitted developers can decrypt and utilize the information protected within it.
You can install git-crypt on Mac easily via Homebrew. You can also easily build the utility on Linux (either Debian or RHEL/CentOS). This means credentials can be shared both with individual developers on the team and with individual servers to which application code is deployed.
Servers (and individuals) can either have their own GPG keypairs or use repository-specific symmetric secrets when protecting credentials. If using symmetric keys, you will still need a way to securely share these keys between collaborators (among the development team and to any deployed servers).
The Good and the Bad
git-crypt is a fantastic utility that allows us to keep all of our data in the same spot and automically control who (or what) has access to secrets’ plain text. It uses strong cryptographic keys and leverages existing public key infrastructure for access control.
The biggest downside of working with git-crypt is its requirement to either use GPG itself (requiring additional installed utilities) or to share symmetric keys between developers and systems for access to credentials. If you have a utility with which you can securely distribute symmetric keys, you might as well use the same utility for sharing the credentials themselves.
On its own, git-crypt is merely an encrypted storage system for secrets. It’s incredibly useful for keeping secrets alongside the code that uses them. It also enables fine-grained access control through specific GPG keys. git-crypt does not, however manage loading these credentials into the environment for use by the application.
For that, you might want to consider one of the various “dotenv” packages, available for just about every programming language available.
Next week we’ll move beyond the simple, local utilities of Credstash and git-crypt and study a more distributed platform that integrates with server provisioning tools: Hashicorp Vault.