In my Using PDM posts, I mentioned that I was rebuilding
the backup tools for my blog. Using such tools requires that I keep a couple of
my passwords, the ones I use for databases, in plain text, which is clearly not
ideal, especially not if I want to use GIT to manage them. I decided to try
git secret to store my credentials. Here's how it works.
git secret. Git Secret stores anything you've
marked as "secret" in a hidden directory under your project, encrypted with your
Gnu Privacy Guard public key, and which in turn can only
be decrypted with your private key. By combining a folder for your secrets in
your project with
.gitignore and Git Secret, you have a much better chance of
storing secrets with your project that are safe from prying eyes.
Important: You must have a global
[user] block filled out, both
Once it's installed,
cd to any project that has a
.git folder and has
secrets you want to store. With those, you can initialize the secrets folder:
$ git secret init
$ git secret tell -m
The second command tells Git Secret to use the email address on record in your
.gitconfig file, and to look in your
gpg key collection for the key
associated with that email address.
I kept my configuration secrets in a folder named
config, so hiding them from
git and adding them to my secrets was as simple as:
$ echo 'config/*' >> .gitignore
$ git secret add config/blog-backups.yaml
$ git secret hide
The file I wanted to keep secret is now complimented by a new file,
config/blog-backups.yaml.secret. If you're ignoring the folder, you must
explicitly add this file to the files you want git to track:
$ git add config/blog-backups.yaml.secret
You can now safely commit your secrets to your repository.
To get them back, you can check out the repo and restore the secreted files:
$ git secret reveal
This will decrypt all the secreted files in your repo, provided that you have the same email address and GPG key as before.
Git Secret still seem fraught with the kind of risks taken when you fail to completely automate secrets management. You could forget to ignore an important configuration file, or you could lose the secret keys needed to get them back. But it's a big improvement over not storing your secrets in a repo at all, leaving them to get out-of-sync with the project.