I recently encountered a possible security concern while using Agenix or Sops-Nix for handling user secrets. I would appreciate your feedback.
The issue arises when multiple machines host users who rely on different subsets of their secrets across those systems. I include Agenix and Sops-Nix in the title because they should be similar for this topic (I only use Agenix currently).
Consider this simple example:
- system_secret1 → machine1, machine2
- system_secret2 → machine1
- system_secret3 → machine2
- user_secret1 → user1
- user_secret2 → user1
- user_secret3 → user2
These secrets are encrypted with machine private keys for system_secrets and user private keys for user_secrets.
Now examine machine1, which features user1 but uses only user_secret1 in its configuration. If this machine is compromised, one might expect system_secret1, system_secret2, and user_secret1 to be exposed.
Unfortunately, that is not the case:
Because the attacker has only machine1’s private key, system_secret3 remains protected. On the user side, the attacker holds user1’s private key; if they can reach the encrypted user_secret2, they can access it. Since only user_secret1 appears in the machine config, safety might seem assured. The unexpected problem is that ALL encrypted keys for user1—whether used or not—are included in the nix store (thanks to u/sighery for the hint) and are compromised by attack on any machine user1 exists.
This attack surface is unnecessary for key management and stems from NixOS architecture. For me, this risk was unknown.
Naturally, your specific key management use case determines whether you face this risk at all or find it tolerable. My question is about the general attack surface and possible mitigations.
Perhaps my assumptions are flawed or a workaround exists (beyond avoiding user-key secrets and relying only on the lower-risk system key portion).
Thanks for your input.
--------------------------------------------------
SOLVED
Thanks everyone for the valuable feedback - never would have found the root cause myself !!!
TLDR for anyone else who stumbles on the same issue:
The root cause for this unexpected behavior is that I use a configuration which self references to the flake in several cases. This makes the repo itself a dependency and results in being copied into to nix store also in remote installed machines.
