We all had that “oops” moment when we realized that we checked-in a password, a private SSH key or a token in Github.
You may think that is OK, that you can just remove it, and it will be gone. But that’s the thing: once it is out there, you never can be sure it was not captured. Also, GIT keeps history. So, unless you rewrite GIT’s history - the key is still there.
What to do next?
But, as GitHub’s article points out, you need now to consider this data to have been compromised. The next thing to do is to change that password or key right away, deploy the changes through your automated continuous delivery pipeline and you’re done.
You deploy manually? Well, get ready for long hours spent searching for that key or password and to change it. There is no way around.
How can I prevent this?
Good news, we can prevent this from ever happening. It requires you to do something.
Amazon released in Open Source git-secrets, which “Prevents you from committing passwords and other sensitive information to a git repository.”. Sounds like this is exactly what we need!
git-secrets installs as a GIT hook, so that it can detect the issue right away
on your PC, before it hits the repository on GitHub or GitHub enterprise.
You may want to also add
git-secrets in a Jenkins
This is a bit late, as the secret will hit the server. But it makes you aware
of the situation and you can act on it.
How do I store secrets securely?
OK, you know you do not want the secrets in the GIT repository, next to the code. But you still need to store secrets somewhere.
If we consider secrets to be “configuration”, then the 12 factor app recommends to use environment variables, which you can protect, and source as needed. It’s not perfect, but definitely a good step forward.
For better security and complete secret management, a dedicated solution like Hashicorp’s Vault will do wonders.