-
Notifications
You must be signed in to change notification settings - Fork 123
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support rules from flake output (nixosConfigurations) #86
Comments
On the one hand this is cool because it would mean one less file and possibly quicker setup. On the other, it means we'd have to evaluate all the nixosConfigurations to manipulate secrets. Where would you specify what users have access to the secrets? |
Couldn't it be just an option at the same level as 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;
age.secrets.secret2.user = "user1";
age.secrets.secret2.group = "mygroup";
age.secrets.secret2.mode = "644";
})
];
}; Was just the first that came to mind, I might have missed implications here |
Could the opposite be possible? I.e. refer to
|
Why can't we instead look for some other flake output? For example, have an option to evaluate |
Having them inside the
This makes sure everything is build (and cached) and working before the configuration is actually applied to the host. |
That's a fine idea robryk. Pinpox they aren't proposing moving the config out of nixosConfigurations. They're proposing moving the agenix CLI config into the flake. |
Oh sorry, I misunderstood then. Still interested in this feature btw. |
I decided to see if I could implement something like this, and immediately ran into an issue: Pulling Anyone have any suggestions? |
Only if the path is of type |
I think that'd require changes in agenix itself to work correctly; although possibly just in the option types. Unless I'm reading this incorrectly it seems to also be the path as deployed on the system, rather than the path relative to where It seems possible have the I could maybe do it by adding a secondary file option, where one is a path for deployment and another is a string for local configuration. I'm not sure that's a strong improvement over the current state, though. Is it possible to have a string (referencing a local path) that can be converted into a path? Since the other direction results in the full store path. Maybe I'll see if I can make that work. |
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:
nixosConfigurations
could be used directly resulting in a rule set equivalent to:Since you 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 text was updated successfully, but these errors were encountered: