 | agenix | 344 Members |
| age-encrypted secrets for NixOS https://github.com/ryantm/agenix/ | 101 Servers |
| agenix | 344 Members |
| age-encrypted secrets for NixOS https://github.com/ryantm/agenix/ | 101 Servers |
| Sender | Message | Time |
|---|---|---|
| 10 Mar 2025 | ||
 kiwicutter | Yeah fair point tbh, as long as the secrets don't prevent the system from running itll be easy enough to rekey right after. | 08:42:17 |
| kiwicutter | I guess the host keys will only be generated during a first startup though and not already during nixos-install? Else one could already check those and rekey right after the install.. | 08:43:32 |
 Daniel Rodríguez Rivero | As far as I know, they just put empty files in places, instead of failing. Is that what agenix does too? | 08:54:16 |
| Daniel Rodríguez Rivero | But in order to rekey, you need to do that in an environment where the secrets are available. No? so you can't do that in the host being built | 08:57:41 |
| kiwicutter | As long as i have my "master" key i can just go about and re-key everything no problem or am i missing something | 14:50:10 |
 Gaël joined the room. | 22:27:10 | |
 Charles ⚡️ left the room. | 22:30:10 | |
| 12 Mar 2025 | ||
 xored | Hi everyone, I've been trying to use the path option to decrypt a secret to $home/.config/ntfy/client.yaml, but is not working, my best guess is that is not being evaluated? | 02:53:43 |
 elikoga | Are you using straight up "$home"? Either that's not evaluated or placed at the home of the agenix activation script user (probably root?) | 02:56:11 |
| xored | No I am using an interpolated string | 02:56:48 |
| xored | put that to save typing hahaha | 02:57:07 |
| xored | oh for the love of god, it was wrong name in cfg = config.modulename that i pasted from another file | 02:59:13 |
| xored | no wonder it did not eval | 02:59:23 |
| 16 Mar 2025 | ||
 memyk joined the room. | 12:38:26 | |
| 18 Mar 2025 | ||
 @raijin_:matrix.org | I'm a little confused on how I use Agenix secrets with multiple machines? I have Agenix set up on machine A, and a key on machine A was used to create/encrypt the secrets I installed NixOS on machine B, and I have generated a new keypair to belong to this machine. If I add my new public key to I'm struggling to see how a malicious actor couldn't just download the repo, add their keys, and decrypt? The "original" key (on machine A) has to be used to decrypt at some point right? What am I missing here? Do I just have to share the same keypair across machines? Obviously not, or else why can we configure multiple? | 22:47:03 |
| 19 Mar 2025 | ||
 K900 ⚡️ | You need to rekey your secrets manually on a machine that can decrypt them | 00:34:28 |
| @raijin_:matrix.org | K900: ok, this enables the secrets to be read by multiple users? | 01:51:37 |
| @raijin_:matrix.org | is https://github.com/oddlama/agenix-rekey recommended? | 02:00:16 |
| K900 ⚡️ | In reply to @raijin_:matrix.orgNot necessarily, depends on your setup | 06:45:41 |
| @raijin_:matrix.org | K900: this is my current secrets "architecture" https://github.com/GideonWolfe/nix/tree/main/configs/secrets I did some reorganizing to separate system/user secrets, but I'm not sure how to really make the whole process "seamless" to set up a new machine | 15:25:22 |
| 20 Mar 2025 | ||
 rane [they/them] | raijin_: you'll need the private key for a public key which has "access" to a given age/agenix secret to be able to decrypt it, public key just allows for encryption not decryption. So for example, my workflow is that all secrets can be decrypted by the SSH private keys of machines which need them, and also my yubikey's age key (which is stored on the yubikey and has to be plugged in). If I want to add a new host, I do an ssh-keyscan to get the public key, add it to my list of identies, and then rekey everything. My yubikey is sufficient to rekey because if it is plugged in then I have access to a private key which can decrypt the secrets. Does that make sense? | 20:23:07 |
| rane [they/them] | You set out what has access to which secrets in the secrets.nix file and you can lock it down to just your private key (which can be on a yubikey) and just the SSH private keys of the machines which need access to those secrets. The SSH private keys stay on those machines so an attacker would already have to have access to those machines with sufficient access to read just the secrets you were using on that machine or the SSH private key (which is usually only accessible to root). But if they had root on your machine, or access as a service account where you'd configured the permissions on a secret to be readable by the service, on the target machine, they'd be able to read the secret. But in most threat models that would be expected and acceptable, if someone is already on the machine then at least you're able to limit and restrict the secrets to just what is needed for each given service + user. | 20:25:45 |
| rane [they/them] | I just have agenix -r with the appropriate identity for my yubikey age key in a Makefile I run when I need to rekey everything (i.e. add a new host's SSH public key) | 20:27:04 |
 Valodim | Setting a different default private key location via environment is one thing I miss in agenix from sops | 20:28:32 |
| 21 Mar 2025 | ||
 adjivas joined the room. | 01:50:53 | |
| 22 Mar 2025 | ||
 isabel joined the room. | 00:42:36 | |
| 23 Mar 2025 | ||
 @sleepymonad:matrix.org left the room. | 07:42:13 | |
| 24 Mar 2025 | ||
| @raijin_:matrix.org | rane [they/them]: thanks for the reply. I think I get the gist of what you're saying. Currently I have things divided up between "user" and "system" secrets, so a system secret is decrypted by a host SSH key and is used for a system service like a running docker container, etc. This is mostly "done" because I'm only deploying to one host for now. Whereas a user secret is decrypted by a user-generated SSH key. Passwords to email clients, etc. This has been working great but now that I am re-using the same user config on another machine, I need to rekey. I added that new user-generated public key to my secrets.nix, and added the new user as a target recipient to one of the secrets, and ran | 05:49:08 |
| rane [they/them] | Is there a reason you'd like to have this logical idea of "user" and "system" keys? My understanding (at least based on my usage) is that it's the machine that will need to decrypt the secrets it has access to, at each boot (because they are not stored decrypted on disk). I treat all my secrets the same, with the exception of how they are used and which machines need access to them. Some secrets are locked to specific owners with specific permissions but they all have the SSH public keys and my yubikey as a public key in the identities which have "access" to them, if that makes sense? Even if they are used by home manager, or just for setting up my user account. So for example, I set my user password as an agenix secret which is encrypted with my yubikey as one identity, but then the machines where I deploy that password to my user account are also added so they can decrypt the secret. This is the same for secrets used by system services, I also add my yubikey so I can rekey on my workstation when I add or remove ssh keys from my identities configuration. | 08:00:47 |
 Nicolas Lenz changed their display name from Nicolas Lenz to Nicolas. | 13:40:28 | |