Don't store encrypted secrets in git if you can avoid it.
When someone has unintended access to secrets (for example, the developer you just fired), you need to rotate both the key and secrets to have any semblance of security. Ideally you use deterministic encryption to create the secrets too.
We should be able to agree that not storing secrets in your repo dodges all these problems nicely.
If anything, I like the git repo idea b/c — presuming that the repository stores a history of who had access to what, when — it removes the question of whether you need to rotate a secret. You can look at the history, and if the secret didn't get rotated when access was removed or at some time afterwards, you know you're not secure.
Compare that to say, a random file somewhere, say on a deployment node in deployment code, or alongside that code so as to keep it out of a repo, that just keeps the latest copy of the secrets, where one doesn't know when access was revoked. Do the keys need rotation?
The page says "When someone is out - just delete his public key, reencrypt the files, and he won’t be able to decrypt secrets anymore." but doesn't talk about rotating the secrets.
This practice seems unnecessary to me.
If someone has access to a shared secret and then shouldn't you should assume the secret is now compromised and rotate it. Rotating the keys doesn't solve this problem.
It's a bad idea to store secrets in any form in your source code repository.
Obviously this is a huge hassle and isn't easily done with all kinds of secrets (which is what I think you're getting at?). But it's also often necessary.
This doesn't have to be a Git repository, nor does it have to be the same repository as the code which uses the secrets.
> it's incredibly helpful to store the configuration along with the code
It's helpful, but ultimately means that the ciphertext is potentially available to the world and existing keys may decipher it in perpetuity. Thus this is not a recommended tradeoff to make.
How is that different from the case of an employee having written down the secrets and leaving the company later on? In both cases the employee has had access to the secrets and in both cases the only way to be secure is to change them.
a rogue employee who created a secret, or any engineer who had to access that secret to get their job done, is always going to be able to use that secret value, regardless of where the encrypted blob is stored.
seems like we should be making it easier to rotate secret values often and automatically.
