4 ms·
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
by sureglymop 10mo 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).
- lucyjojo 10mo agoit 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.
- sureglymop 10mo agoConsider 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.
- lucyjojo 10mo agoat 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.)