Avoiding information leakage in multi-host deployments

Yeah this is a bit of a problem, depending on how you deploy.

If you have the repo on your machine and use nixos-rebuild switch --target-host=$target, then you will only copy the final store paths, not the sources as far as I know, so that would somewhat circumvent the issue you’re describing. Using terranix might make this a bit easier, depending on how big your infrastructure is.

Lazy evaluation is part of the evaluation semantics of the Nix language. This means that it can prevent files from being included only when the files are imported during evaluation time. However, with flakes, this is not the case right now. As you discovered, the whole flake is copied to the store for it to be evaluated. It doesn’t necessarily have to work that way. A flake could be evaluated without copying, only the inputs must be in the store, and there is an open draft PR to implement this, but it still has issues.

There’s also an RFC for adding ACLs to the nix store, which could somewhat solve this problem.

As for how to actually solve this issue right now: you could store the client-specific configurations in their own flakes as default and put those in your repo separately. For the common configuration values, you can add another “common” flake that the other ones just use as an input. This is a little annoying because you have to always run nix flake update for every client when the “common” flake is changed, but you can script your way out of that.

For the secrets, a simple solution is to have a well-known location outside of the Nix Store where you store a script that the environment setup from your config sources on startup. This could be populated from a key-value secret store, or you store these files with git-crypt in a separate directory in your repo that is not visible to the client configuration flakes.

Thinking about it, you could potentially store an encrypted file containing all secrets for every client in your flake for every single client, and only deploy the decryption key separately. The only “information leak” in that case would be that there are secrets, and the file size can indicate how many, but that’s it.

1 Like