Handling Secrets in NixOS: An Overview (git-crypt, agenix, sops-nix, and when to use them)

Guides
1

I have spent a while getting familiar with the most popular solutions I’ve seen for NixOS secrets management and I wrote up all my knowledge and opinions on when you might want to consider each solution here.

13 Likes
2

Using git-crypt will ensure that your secret files are encrypted when you push your repo to a remote like GitHub, however, using this approach means that your secrets will end up in /nix/store unencrypted, which is readable to all users on a machine. If you’re exclusively managing your own physical machines, this isn’t really an issue for you to worry about.

I’d be much more careful with this statement. Security without a threat model is somewhat vague, of course, but a lot of measures that NixOS as well as pretty much all services that deal with secrets provide depend on it being difficult to cross the user barrier.

Most services will have their own users - not just humans - to prevent other (potentially exploited) services from being able to interfere with them. If you add secrets to your nix store, all systemd “hardening” becomes basically useless at protecting those secrets, and if user passwords are some of those secrets all other on-host security measures break down.

You’re entirely relying on there being no bugs in any of the network-facing software you use, and on the obscurity of NixOS. If you use remote build infrastructure the secrets are exposed to any builders, too. All this goes well beyond “if you’re exclusively managing your own physical machines” IMO.

Rather than giving a hard statement on which use cases may be able to use it (I can see this being alright on a totally air-gapped system, for example - it all depends on the threat model), just state that it exposes secrets in the nix store. And maybe reconsider if your personal use case really doesn’t care about this at all.

defaultSopsFile = ./secrets/secrets.yaml;

You may also want to be careful about recommending this without any caveats. sops is pretty explicit about public repos being a threat in the eyes of their threat model. I imagine similar things apply to agenix.

Both projects provide mechanisms for supplying your secrets in a file pushed to the host separately, so it doesn’t need to be in public git repositories.

7 Likes
3

These are all great points and I have nothing to add. If you don’t mind, I’ll add a link to your comment in the article later so that there is more information for users to make informed decisions.

2 Likes
4

I just wanted to thank you for this write up! I will make some use of it soon to try out some of these solutions! :slightly_smiling_face:

1 Like
5

you might want to add secrix to the list, give it a whirl, you may like it.

or you may not

3 Likes
6

I’m not sure why they’re having a problem with agenix decrypting secrets at boot, but it definitely does that, so they have some problem, maybe disk encryption or activation script ordering.

1 Like