With agenix, you can encrypt your secrets, such as API keys, and have them stored in your git repo alongside the system configuration (which in nixos is just a bunch of text files). Then you only need to provision the server with the ed25519 private key corresponding to the pubkey the files were encrypted with, and agenix will automatically decrypt the files on boot and place them in /run/agenix, with the specified access permissions.
So you still need a secret when provisioning, and you need to handle change management for that, and storing it securely outside of the git repo. And agenix did not change that workflow, or did it?
I only need to care about my SSH key(s). Which I had to anyway. But now the secrets for all the services (except SSH) lie right besides their config. Any change in one or other is directly visible in git log.
In short, age cut down on the number and types of secrets that I have to manage out of band. Which is very good. It's always easier to be able to remember 2 things (config + SSH keys) than 2+n things (config + SSH keys + whatever secret mechanism any service uses, times number of services).
So like SOPS, but specific to nix somehow? What is the advantage of the nixy integration here vs the universality of SOPS? Better native integration with NixOS?
To clarify maybe, NixOS puts all configuration and program files it handles in a world-readable object store on disk. If you want to manage secrets on NixOS securely, you have two choices:
- Manage it out of band. That negates all of the benefits of NixOS, at least for those files. (I.e. you would need additional deployment steps, rollback wouldn't work, you would have to stop and migrate system services that depend on those secrets yourself, etc.)
- Encrypt it and only decrypt it on activation (which happens when switching to a new config or on boot). agenix and nix-sops (the premier SOPS/NixOS integration) are two libraries that you can include in your config to do that. With this, the world-readable store only contains encrypted secrets.
Of course with #2 you still have to manage your private keys (age or whatever SOPS uses) out-of-band but that is significantly less work since those aren't expected to change nearly as much. You can also generally decouple that from your day-to-day deployment workflow.
