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 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 is a bash script based on
git-secret allows you to encrypt individual files for storage inside of a
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-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
Access permissions can be managed by adding individual gpg keys, similarly to
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.