Comment by sureglymop
2 days ago
I understand the thought but my honest advice is: do not commit secrets to git, even if they are encrypted.
Secrets are not configuration, they are state (and I would say, an even stricter form of state that should ideally only exist at runtime in memory).
it strikes me as reasonable for 1-10 people teams (well, small businesses).
the real problems/risks only creep up for mid to big size businesses, which i don't think the tool is concerned with.
from my understanding the big problems would be:
- auditing/leaking risks that come with bigger headcount/turnover - bad uncontrolled use & problems with policy - operational inertia when problems happen
these are not real for most (healthy) small teams.
the really touchy problem is decryption key management and running state management.
Consider even just the chance that at some later point you want to remove the secrets. Now you have to rewrite history and also force that on all contributors.
at that point keep them in there, quit using the "secrets in repo" strategy from now on and rotate all your secrets in your new vault.
you also have the option to cut a new repo. it's a small team, you don't have behemoth inertia.
(secrets in repo if your code is open-sourced is indeed not a good idea at any scale. it's also a bad idea if your secrets cannot be easily meaningfully rotated, like putting your social security number in a secret.)