For automation, we want to store as much text as possible in our git repositories, and any binary artifacts in an artifact repository (like Sonatype’s nexus). However, Git can be a dangerous place to ever store passwords. If a bad guy ever acquired access, he could roll back in time and find every password you’ve ever stored there. While some applications support in-value encryption like Jasypt, most infrastructure software does not. Even if it did, I’d have a patchwork quilt of solutions. I have used Chef’s data bags for this, but Ansible’s fact management and encryption require a password to be entered every time. Enter git-crypt [1] [2].
Sample Attributes file
Pro #1: Simple configuration of what is encrypted. Git-crypt is setup as a filter in the .gitattributes file. This gives us our file pattern support. In this system, I only encrypt the files I want. For example, in my Ansible repository, I have a folder of secret passwords.
# cat secrets/.gitattributes *.yml filter=git-crypt diff=git-crypt
Initializing a git-repo for the first time with git-crypt
Pro #2: Your day-to-day workflow is unchanged. Even though the central git server has all my passwords/keys encrypted, all git operations including push, pull, commit, and diff are the same, and the encryption is done transparently for us. This helps with sharing and code reviews, where people can easily review the code with any system plugged into git, but most of the time they don’t actually need to decrypt the passwords/keys.
# git crypt init
Adding someone new to the git-crypt repo
Pro #3: Supports GPG keys. Giving someone access to the encrypted values is safe and secure. They email me the public key, and I import it, trust it, and add the encrypted version of the symmetric key to the repository.
Export from new user
gpg -a –export “Jonathan Malachowski”
—–BEGIN PGP PUBLIC KEY BLOCK—–
Version: GnuPG v2.0.14 (GNU/Linux)
….
=RmtA
—–END PGP PUBLIC KEY BLOCK—–
An existing user must now give the the new user access. In the following instruction we will import a key, look at what the key identified itself as, mark the key as trusted, then add that user to the git repository, and finally push up that change.
Import a new user (giving access)
gpg --import jon.malachowski.key gpg --list-keys gpg --edit-key >> trust >> 5 git crypt add-gpg-user #this creates a commit with the new user-specific encrypted symmetric key. # git log commit 68d826f0a40e1e66a7aeadaa5c948dc20c151a2f Author: Jonathan Malachowski <jon.malachowski@coveros.com> Date: Tue Feb 16 16:09:11 2016 -0500 Add 1 git-crypt collaborator New collaborators: E7E11342 Jonathan Malachowski (My First GPG KEY) <jon.malachowski@coveros.com> git push
Finally, the new user can pull down the change and unlock the repository. The magic of git filtering will make it so we never notice that the files are encrypted again until you re-lock the repo, or have to clone it again.
Unlocking a repository
# git crypt unlock
Until cookie monster has no more cookies,
Jonathan Malachowski
