I’ve worked on many projects where sensitive information is stored in a git
repository. This includes SSH keys, SSL private keys, API keys, passwords, and client secrets. This practice is easily labelled Not Good.
You might be thinking, “Why should I worry? Our GitHub repository is private, and only our team can access the secrets!”
A private repository on GitHub or GitLab may seem like a safe storage area, since access is limited to a small set of specified parties. However, many teams don’t think twice about allowing third party services to access these private repositories. Once you’ve enabled access, these services now have permission to read your secrets. Even if the service isn’t malicious, thereis the chance that there is a vulnerability in the services that could be exploited to expose the files. Or perhaps there is a configuration flaw in your build server which grants everyone on the internet read access to your projects.
Storing secrets in our repositories is alluring because of its convenience, and I found myself recently tempted by this practice. I spent time investigating solutions to the secret storage problem and came across three easily incorporated projects:
I currently use BlackBox, as it was the first solution I discovered. However, I will be migrating to git-crypt
because it offers a superior workflow with little user involvement.
BlackBox
BlackBox was created by Stack Overflow, initially to support secret storage for use by Puppet. Unlike the other two solutions I’ll discuss, BlackBox is the only one that supports a multiple version control systems.
Protected files are encrypted with the public keys of all trusted users. If access needs to be revoked, delete the public key and re-encrypt the files.
BlackBox can encrypt and decrypt individual files. If you are using Puppet, you can also encrypt/decrypt individual strings.
I recommend BlackBox for developers who do not use git
or work with a variety of version control systems.
git-secret
git-secret
is a bash script based on gpg
. git-secret
allows you to encrypt individual files for storage inside of a git
repository. git-secret
provides commands to encrypt secret files before pushing to the server and to decrypt them for local use.
Protected files are encrypted with the public keys of all trusted users. If access needs to be revoked, delete the public key and re-encrypt the files. They will no longer be able to decrypt the secrets.
You can install git-secret
with apt
, yum
, and brew
.
git-crypt
git-crypt
is a program that operates similarly to git-secret
. Files that should be encrypted by git-crypt
are tracked in the .gitattributes
file, similarly to git-lfs
.
Access permissions can be managed by adding individual gpg keys, similarly to git-secret
. git-crypt
also allows you to export a symmetric key which can be provided to collaborators.
Aside from an initial unlock
command that needs to be used after cloning the repository, git-crypt
encryption and decryption operations happen transparently. I find this workflow to be superior to git-secret
and BlackBox.
You can install git-crypt through brew
if you are on OSX. Otherwise you can manually compile git-crypt
for your system.
Thanks for sharing Phillip.
Are you still using git-crypt?
Cheers
Benn
Yes, I use it for my personal configuration files and recommend it when my clients are sharing secrets through a git repository.
How do you remove a user in git-crypt?
Thanks for the overview. Quick thing, the link to git-crypt is broken, looks like there is some weird html character escaping going on there.
Thanks for pointing that out, I’ve fixed the links.
One note that all these encryptions are not for encrypting entire git repository and commits, they’re only good for encrypting some specific secret files that you might have in your repository!
I just want to point out that git-crypt is installable with apt, in all current Debian distributions and derivates thereof