I have a config that I share on github. I share the whole thing and there are keys in it but they are obviously not the complete key (as is standard throughout the community). Just enough to point to the real key with Nix.
Anyway, I have finally gotten around to learning the power of git-crypt. Today, I went through my whole config and took everything out that could even remotely be used by a hacker to find out security holes in my config (permitted insecure packages, specific hardware ID’s, github username and email address, for example all went into nix files into the secrets folder with imports where they used to reside) and put those files into a folder at top level called secrets. Then, I encrypted all of the files in that folder and pointed the rest of the config to them so they remain encrypted on my github but perfectly usable in evaluation and build of my config derivation.
My question is: Have I done something clever that will significantly decrease the chances of exploit or do you recommend that everyone does this and I’m just late to the security party?
If this technique is just standard, what else could one do to harden their system without causing difficult to solve issues on deployment of their config? For example, I now need to decrypt that folder when I use that config on a new system and anyone else building it wouldn’t be able to get through the evaluation.
I’ve heard of Sops-Nix and other such security handlers. How can I use sops-nix to aid in that initial git-crypt setup when I spin up a new system, for example?
“Don’t store secrets in git” is a pretty good mantra. Use a dedicated secret storage solution instead, and pipe them in during deployments using environment variables.
These aren’t my pgp keys I’m storing using git-crypt. They’re parts of my configuration that I was (until today) completely content to share unencrypted on my git repo. I’ve simply made them very difficult to see to obfuscate parts of my config that could be used to find my vulnerabilities.
Actual PGP keys, api.key, and stuff of that nature is certainly not in that secrets folder.
Take a look at agenix: https://github.com/ryantm/agenix
Good job for doing something. It all boils down to what you are comfortable with, adding security will always add a certain level of inconvenience. Ideally the next step would be to fully automate what you have.
Elaborate does not mean secure, often it’s the opposite as adding complexity adds new ways of failure.
If you are talking about this SOPS https://github.com/getsops/sops it doesn’t change much you need to store the master key somewhere. It makes it easier to operate, but your trust boundary does not move.
