-
-
Notifications
You must be signed in to change notification settings - Fork 13.9k
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
vault: Support secure config file #107323
Conversation
90341c5
to
536f8c1
Compare
I've removed the auto-reload commit. It's just a small refactor that introduces two options now. Existing installations will remain identical. Ping @rushmorem @LnL7 |
This seems like a step backwards. The sysadmin now needs to choose between security vs the benefits of NixOS. There are a number of modules which take config files and replace dummy text with real passwords in a secure way in the |
Which NixOS feature or security aspect does this PR neglect?
That's not a generic solution though. Where the password goes depends on which storage backend is chosen, so the module would have to know about all the backends. |
From the description I've read this PR seems to have the sysadmin choose between security through a mutable configuration file, warning the user the module may not work as expected, or a working, declarative, reproducible configuration ... where a password is stored in plain text in the nix store. |
The only warnings are about reloading and using other contents than
This works. It's declarative. The password comes from the deployer as is usual with NixOps. Perhaps this is what makes this solution a bit limiting? Does seem reproducible to me, certainly on NixOps. @aanderse I guess we could ask the user to write some placeholders in the config file, have a way to map those to files and substitute those before starting? I have no idea how to do achieve that before reloading though. That's important because you want to restart vault as little as possible, to avoid downtime due to unsealing. I guess we could use the JSON format to overlay the sensitive bits from a separate file generically. I'd implement RFC 42-style Too bad Vault doesn't support HCL functions. hashicorp/vault#10633 would make this a non-issue. |
@roberth it seems I didn't read the changes here as carefully as I should have. I believe I understand what is going on now 😆 The sysadmin can specify Thanks for your patience with me, and thanks for making a PR with something so cool in it! |
On the plus side what you have done here never occurred to me before, and is probably something that will useful to me. So again, thank you very much! 😃 |
The module system is underutilized. You can even emulate functions but it's just not obvious that it can behave like that. (Which takes a bunch of explaining 😅 ) |
Hi @roberth 👋 Your ideas here ended up being a bit of a pattern for me in a few nixops networks I have: services.foo.settings = {
# blah blah
};
deployments.keys."foo.conf" = {
text = generators.toKeyValue { } cfg.settings;
user = "foo";
group = "foo";
destDir = stateDir;
}; Secrets management can be a real hassle in NixOS. Not that I have thought it out too much, but I don't see any real problems if we were to add some sort of mechanism like Do you have any thoughts on that? Good idea? Bad idea? Impractical? Any feedback appreciated. Thanks! |
Hi @aanderse, I love this idea! File copying functionality could be added to nixos-rebuild, which is the tool that has knowledge of both expressions and hosts. To get the secret values you can either (Tangent: This marker file could be implemented as a flag in a generic metadata file in It'd be a good idea to reuse NixOps' options, but not its implementation. Its file watching logic should be replaced and simplified by systemd units. Also I don't think we want to have a For copying the files, you'll want to send an archive instead of multiple files, because If you allow the (extracted?) secrets archive "creation" to be pluggable, the same interface could be supported on arion. This could probably be added later though, with a little refactoring. The various deployment tools such as Arion and NixOps can extend the options to add extra secret sources besides the "Nix-builtin" text and file ones. Regarding NixOps we have two options: Another interesting idea is to integrate more directly with systemd-specific techniques, such as privileged execstart(pre) lines and/or LoadCredential. That's more thought than I thought I had. For a first iteration, you could try to keep changes to |
Yes, I would be interested in a general mechanism to handle secrets in NixOS. I already have worked on a minimal module that's similar to |
Oh one more consideration is whether the secrets should be tied to a version of the system profile. This is required for rollbacks, but has the downside of retaining secrets for longer. It should probably be configurable. Some choices may be: keep current generation only, keep one previous generation, keep secrets for each non-GCed generation. We should also remove secrets installed by the current generation that aren't in the new generation before switching. |
NixOps' approach of using systemd units to indicate the availability of secrets provides more flexibility. For instance it supports secrets in ram / tmpfs and rebooting, losing the secrets. If persistent storage of secrets is chosen, installation during activation seems more robust. They're not incompatible though. The module can both provide the systemd units for the secrets and try to install the secrets during activation for the cases where that works. |
I opted for an activation script because I wanted to use the module for user passwords, which are loaded during activation by the |
NixOps offers some units some services so users can wait for the key files to be installed. I believe these could be better implemented as path units. That leaves the options open with regards to when the secrets are installed. NixOps installs them on
Currently it's
This could become
Open question: can we increment the generation number without updating toplevel; when only the secrets change? As a workaround we could hash the secrets and put them in toplevel, but this isn't great because then it can't be built without access to secrets anymore. |
Motivation for this change
Things done
sandbox
innix.conf
on non-NixOS linux)nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
./result/bin/
)nix path-info -S
before and after)