Wouldn’t you want to use agenix nowadays?
I think that is a matter of personal taste or proficiency with age or sops.
And for me the decission boils down to “whatever natively supports home manager first”.
I use a mix of gpg and age keys which sops-nix can support. Like I mention in the post though, there’s plenty of alternatives, this is just the one I like.
As for home manager support, it’s imminent within sops-nix: Implement home-manager support by dasJ · Pull Request #168 · Mic92/sops-nix · GitHub
I’m aware of the PR, and there is also a PR for agenix. An initial WIP for agenix resulted in homeage. Though I would prefer to have all the secret management through the same tool.
I will give it another couple of months before going age-nix + homeage, hoping that I get a single tool before that…
Everything you put in your
.nixfiles, any input files/directories said.nixfiles reference, and all the build output of the derivations said.nixfiles define will end up in your nix store.
This is not true, as evidenced by NixOps deployment.keys.
That does rely on the expression authors to pay attention to certain things, but it is certainly possible not to put certain files in the store.
I’m not suggesting for everyone to switch to such a solution, but it is easier to automate cloud deployments if you don’t have to rekey (and create commits, in e.g. a typical agenix setup) every time you have a new host key.
It would be nice for the key copying functionality to be part of nixos-rebuild, so you can use it on a locally configured system such as a typical developer system. The secrets could be stored securely in /root/ and then copied into the right places with the right permissions at activation time.
Not with flakes, it isn’t, which is a dealbreaker for a lot of people.
Yeah, you can’t use a flake as the entrypoint until lazy-trees is merged. Until then you could use a separate directory outside your flake and make it work with builtins.getFlake, but yeah, that’s complicated and very non-obvious.
AFAIK, agenix uses unauthenticated encryption, which makes it strictly inferior to sops-nix in my view.
The judgement on this might be different for other people, of course, and any well-founded choice should be based on a proper threat analysis.
Authentication really should be happening at a wider scope than the secrets anyway. You should be authenticating the entire configuration, at which point the authentication built into the encryption is superfluous.