Sender | Message | Time |
---|---|---|
20 Mar 2025 | ||
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 | |
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 | |
Setting a different default private key location via environment is one thing I miss in agenix from sops | 20:28:32 | |
21 Mar 2025 | ||
01:50:53 | ||
22 Mar 2025 | ||
00:42:36 | ||
23 Mar 2025 | ||
07:42:13 | ||
24 Mar 2025 | ||
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 | |
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 | |
13:40:28 | ||
I think the main reason is that I was scouring for any examples of how people have set up agenix and I found that the pattern was pretty common, people will have a list like It made sense to me because logically it makes sense that system secrets are:
whereas user keys are
I think my end goal with this setup was to have something akin to what you have, where I have a single source of truth like a Yubikey and then all secrets can decrypt off that. I'm just not quite sure how to achieve this, as you can see I'm having difficulty with the simple task of adding an additional key that can decrypt secrets lol | 15:10:53 | |
My intention is to make setup/maintenance of systems as seamless as possible, and getting the secrets to work is currently a huge pain point.
So this is done within your secret config? I need to implement something like this, because even though I don't have the secrets "assigned" to a host, it still tries to decrypt them during system rebuild and makes the build output "fail". Do you happen to have a public configuration I can look at? Or would you be so kind as to look over my configuration and give me some pointers? https://github.com/GideonWolfe/nix/tree/main/configs/secrets I'd like to work towards a setup like you have where
| 15:17:38 | |
also I don't currently have a personal Yubikey, which model is optimal for this application? any? | 15:23:14 | |
* also I don't currently have a personal Yubikey, which model is optimal for this application? any? And if it does need to be connected at boot to decrypt secrets, what happens if I need to remotely reboot my server? | 15:24:28 | |
26 Mar 2025 | ||
I think you might be mixing up public and private keys - you need the public key to encrypt, the private key to decrypt. A private key only needs to be present when you are decrypting the existing values. When you are editing or creating secrets, you will need access to at least one private key. Every private key has a corresponding public key, which must be "added" in Putting all of this together, if you have a personal private key for admin purposes (i.e., adding and editing secrets), you would give the corresponding public key access to the secrets so the public key is used to encrypt the value. The public keys of any machines (i.e the SSH public key, which | 04:21:27 | |
27 Mar 2025 | ||
Download image.png | 15:59:19 | |
rane [they/them]: thanks so much for your explanations, I think I'm starting to understand. I'm kind of a visual learner, so I diagrammed out my current setup here. Maybe that will shed light on where my misunderstanding lies.
But what public key does this private key correspond to? One of the public keys defined and assigned to the secret in
So I would have a public key entry in
I think I have this part, because when I get a new host (non-server), I generate a new keypair on that machine and add the pubkey to | 15:59:22 | |
28 Mar 2025 | ||
18:16:13 | ||
30 Mar 2025 | ||
02:13:30 | ||
31 Mar 2025 | ||
21:13:40 | ||
3 Apr 2025 | ||
16:18:24 | ||
4 Apr 2025 | ||
12:22:35 | ||
5 Apr 2025 | ||
15:41:33 | ||
8 Apr 2025 | ||
10:39:18 | ||
10:39:52 | ||
9 Apr 2025 | ||
19:06:15 |