There are a lot of great open source tools out there for storing secrets in Git. Depending on your use cases, some will be better for you and your organization than others. In this post we’ll see how some of the most popular open source tools for secrets management stack up against each other.

The tools that we will compare are:

• git-crypt (https://github.com/AGWA/git-crypt)
• blackbox (https://github.com/StackExchange/blackbox)
• sops (https://github.com/mozilla/sops)
• transcrypt (https://github.com/elasticdog/transcrypt)

Note that we will not be reviewing larger solutions like HashiCorp Vault. A production-ready Vault can be a rather large hurdle, especially if an organization is just getting started with secrets management. This article assumes you need secrets management right here, right now, and will review tools that give you the power to do so.

So, without any further ado, let’s get started!

Encryption Basis

Each of these tools are based on either GPG, cloud key services, or symmetric key encryption. See the table below for a comparison:

	GPG	Symmetric key	AWS KMS	GCP KMS	Azure Key Vault
git-crypt	X	X
blackbox	X
sops	X		X	X	X
transcrypt		X

GPG-based tools require users to create a GPG keypair. The public key is used to encrypt and is shared with other users, while the private key is used to decrypt and is only known by one user. “Symmetric key” tools are password-based and work when given the correct password. AWS KMS, GCP KMS, and Azure Key Vault-based tools allow integration with key services from cloud providers.

As you can see from the table, both git-crypt and sops have more than one encryption basis. For git-crypt, this means that encryption can be achieved by using GPG OR by using a symmetric key. With sops, this means that you can use GPG OR one of the cloud services.

Goals

The end-goals of each of these tools are almost the same – check out the table below:

	Transparency with git	Whole-file encryption	Partial-file encryption
git-crypt	X	X
blackbox	X	X
sops		X	X
transcrypt	X	X

All but sops are designed to be transparent with git, meaning that the tools have mechanisms built in to ensure that files in source control are encrypted without much effort from users. They help ensure that a “git push” will not accidentally push plaintext secrets to git.

At this point you might be wondering, “Why is sops here if it doesn’t encrypt transparently with git? Isn’t this a post about git encryption tools?” The reason is because of how it handles key-value based files, such as YAML and JSON. When encrypting these types of files, sops will leave the keys unencrypted but will encrypt the values. There are often cases, especially in configuration management, where these types of files need to be encrypted in git but would also be convenient to see what kind of information these files contain. While sops does not provide native git transparency, tools like git-secrets can be used as a compliment to sops to help ensure plaintext secrets are not pushed to git.

Finally, all of these tools support whole-file encryption, in which secrets files are encrypted in their entirety.

Workflows and Ease of Use

None of these tools are particularly difficult to use, but they do provide their own sets of quirks and operational challenges.

GPG

Let’s talk about the GPG-based tools for a minute. The basic workflow for each is as follows:

1. Initialize the repository with the encryption tool
2. Create GPG keys for users that will be allowed manage secret files
3. Add the corresponding public keys to the tool
4. Designate the files that should be treated as ‘secret’
5. Encrypt the files using the tool
6. Repeat steps 2, 3, and 5 for each new user that is granted permission
7. To revoke a user, remove the user and repeat step 5

In theory this is simple enough. You can refer to each tools’ documentation and probably agree that the workflow is easy to pick up. One operational issue that comes with this, though, is the maintenance of GPG keys. Your team will need to back up its GPG keys to prevent a lock-out scenario in case GPG keys are accidentally deleted. If you are using the tool for automation, you will also need to consider who will be responsible for creating and maintaining keys for that service. Additionally, if you need to add, remove, or rotate a key, you’ll need to re-encrypt each file for the changes to take effect.

Subtle Differences

While each GPG-based tool provides a similar experience, there are some advantages and disadvantages to take note of:

• Git-crypt cannot remove GPG users natively, which means step 7 above is not easy to do. There are workarounds out there to allow you to do this, but it’s not a built-in feature of the tool.
• Git-crypt will transparently perform step 5 above on a “git push”, even when new users are added.
• Blackbox provides a “blackbox_update_all_files” command which performs step 5 by re-encrypting secret files all in one command. This comes in handy in key rotation and adding/removing GPG keys, in which all files need to be re-encrypted.
• Sops makes key rotation and adding/removing GPG keys the most difficult, requiring you to go back and re-encrypt each file manually.
• Blackbox provides a “blackbox_list_admins” command that will return the registered users’ email address that corresponds with their GPG key. This makes it easier to discern who has access to the secrets than trying to map plain GPG fingerprints.

Cloud-Based Key Services

Here is a sample workflow using sops with Amazon KMS:

1. Create IAM entities
2. Create KMS master key
3. Grant IAM entities access to the master key
4. Add master key to each secret file with sops and encrypt the file (adding keys and encrypting is usually one step with sops)
5. Re-encrypt when adding or removing master keys

Sops is the only tool in this post that allows users to configure encryption with a cloud-based key service. This eases much of the operational burden that GPG-based solutions carry. Take Amazon KMS, for example. In this case, the master key is added to sops, and access is controlled to secret files via IAM policies. Adding and removing users is as simple as granting or revoking permission with IAM, meaning that secret files do not need to be re-encrypted when changing permissions, since nothing changed from sops’ perspective. This solution does come with its own set of operational challenges, however. Each member of the team must have an AWS account before they can access secret files. Additionally, admins must configure and maintain the IAM policies and KMS master key(s).

Symmetric Key Encryption

The workflow for symmetric key-based tools is probably the simplest:

1. Initialize the repository with the encryption tool
2. Designate files that should be treated as ‘secret’
3. “git push” to transparently encrypt the files
4. Share the symmetric key with other users who need access
5. Rotate the key each time a user should be revoked access

Git-crypt and transcrypt will both provide a complex password as the symmetric key. The operational challenges here are to find a secure way to share the symmetric key and to be sure to rotate the key each time a user is “removed”.

Subtle Differences

Let’s go over a few differences between git-crypt and transcrypt, our symmetric key-compatible tools:

• Git-crypt is compatible with both GPG and symmetric key encryption
• Git-crypt does not support symmetric key rotation, so step 5 cannot be completed if using this tool with a symmetric key
• Transcrypt provides a convenient –rekey command for key rotation

Other Features

Here are some other features and characteristics of these tools that weren’t already mentioned.

	editor-in-place	auditing	repo-level permission	file-level permission
git-crypt			x
blackbox	x		x
sops	x	x		x
transcrypt			x

As shown in the table, both blackbox and sops feature an “editor-in-place”. When this feature is used, the tool will decrypt the file and open a text editor specified by the $EDITOR environment variable. The user can then make in-place edits to the file before it is saved and re-encrypted. This allows users to modify secret files without requiring them to first be decrypted-in-place.

Sops is the only tool in this post that provides an auditing feature. This feature allows sops usage to be tracked and monitored by forwarding events to a database. There’s a certain amount of setup required for this, so check out the sops readme for more information.

Git-crypt, blackbox, and transcrypt each handle access at the repo level, meaning that if you can view one decrypted file, you can view them all. Depending on your use case, this is either a feature or a misfeature. Sops handles permission at the file-level, meaning that users that can view one file cannot necessarily view other files in the repo.

Thanks for Reading!

Whew, this was a long one today. If you made it to the end, thank you for reading. Hopefully this post provided a high-level overview of each tool and will allow you to make an educated decision about secrets management moving forward. For more information on each tool, please check out the GitHub page for each (provided at the beginning of this post). Until next time!