Anyway, just want to say that Age is great!
P.S. The author also did an analysis of Restic the backup tool [2] which also prompted me to setup nice backup solution for my machines. Pretty cool.
[0]: https://github.com/ryantm/agenix
Anyway, just want to say that Age is great!
P.S. The author also did an analysis of Restic the backup tool [2] which also prompted me to setup nice backup solution for my machines. Pretty cool.
[0]: https://github.com/ryantm/agenix
Unfortunately, it doesn’t support groups.
For a solution that scales to teams, check out SOPS[1]. You have to do a little more work to be sure that secrets are ignored in the repo but it works reasonably well and is well known.
Transparent support at the editor level (age.el) sounds really nice though.
In terms of NixOS integration, both are on equal footing.
I'm just unfond of yaml is all.
- 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.
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).
A lot of secrets are just things like, backend and frontend of some service need to be configured with matching keys, but are both running on the same device. In that case you could have a systemd service which just generates a new random key if it doesn't already exist, and then ensure that the dependent services wait for that service to complete. That way you don't have to store anything in git for those at least.