Support rules from flake outputs (nixosConfigurations)
pinpox opened this issue · 2 comments
Just an idea I wanted to propose:
Would it be possible to support reading rules from another flake's output instead of a separate secrets.nix
file?
E.g. If I have a flake defining my systems like this:
{
outputs = { self, nixpkgs }: {
nixosConfigurations = {
system1 = nixpkgs.lib.nixosSystem {
system = "x86_64-linux";
modules = [
({ pkgs, ... }:
{
# Config ...
age.option-to-set-key = "ssh-ed25519 AAAAAAA...";
age.secrets.secret1.file = ./secrets/secret1.age;
age.secrets.secret2.file = ./secrets/secret2.age;
})
];
};
system2 = nixpkgs.lib.nixosSystem {
system = "x86_64-linux";
modules = [
({ pkgs, ... }:
{
# Config
age.option-to-set-key = "ssh-ed25519 AAAABBB...";
age.secrets.secret2.file = ./secrets/secret2.age;
})
];
};
};
};
}
nixosConfigurations
could be used directly resulting in a rule set equivalent to:
let
system1 = "ssh-ed25519 AAAAAAA..";
system2 = "ssh-ed25519 AAAABBB..";
in
{
"secret1.age".publicKeys = [ system1 ];
"secret2.age".publicKeys = [ system1 system2];
}
Since you only plan on supporting flakes it seems like an extra step to have to write a secrets.nix
file, as the information is already present in an organized form. The --rules
flag of ragenix could be expanded do accept a flake path or an additional flag (e.g. --flake
) implemented the same way as other tools like nixos-rebuild have.
I might have not considered something, let me know what you think or if this is a bad idea. This could even serve as an alternative for #48, as there would no longer be a reason to have globs since you don't need to define the rules at all.
Thanks for your proposal!
I already thought about having something similar. Currently, the secrets.nix
schema does not accept arguments as (r)agenix
is not aware of any (flake) inputs. This means, one cannot even use lib
and friends. On the other hand, we'd like to avoid breaking compatibility to agenix
. Your proposal to extend the NixOS module and read the configuration from ragenix
could be a good idea, although I haven't thought it through entirely.
This probably should be discussed upstream.