Secret management support

[bbigras]

Like Nixus has.

[bbigras]

We're using a separate NixOS module for that (see https://github.com/serokell/serokell.nix/blob/master/modules/vault-secrets.nix). For now, approle secrets (which authenticate the server to fetch the actual secrets from Vault) are deployed using a separate script. We're considering integrating deploy-rs with that script by implementing a mechanism for pre/post deploy "local" hooks, though.

https://old.reddit.com/r/NixOS/comments/k0utpw/our_new_nix_deployment_tool_deployrs/gdktjit/

[notgne2]

Some kind of functionality that will make this possible is definitely planned, either native, a plugin system, a simple hook system, or something else

[pinpox]

+1 for this. I'm using pass for my secrets currently, would be nice to have a way to integrate it like krops.

[antifuchs]

I'm using sops-nix for this purpose; haven't had to adjust anything to migrate to deploy-rs from nixus - I can recommend it. (Edit: More importantly, I don't think the deploy tool needs any special affordances for the deployed configuration to do reasonable secrets management!)

[pinpox]

I'm using sops-nix for this purpose; haven't had to adjust anything to migrate to deploy-rs from nixus - I can recommend it. (Edit: More importantly, I don't think the deploy tool needs any special affordances for the deployed configuration to do reasonable secrets management!)

I've seen sops-nix but if I understand correctly, it requires me to put all secrets into one special file and won't play well with my existing password manager. I'll consider it as an option, but having all my secrets in one central password manager is a big plus for me.

I imagine supporting the execution of a "password command" like pass machines/host1/token that return a string wouldn't be that difficult to implement and a great feature to have.

[antifuchs]

Mechanically, sops (and by extension, sops-nix) is quite similar to pass: You check one or more encrypted files into your version control, and sops takes care of managing the "recipients" (both the users that can edit it, and the server identities that can decrypt it) for the secret.

Similarly, sops-nix puts the encrypted file into the store, then an environment activation task uses the machine's credentials (ssh private key or KMS or other key provider) to decrypt the secrets into a ramfs mount in /run/secrets.d/.

Understandable if you have a secret-management solution that works for you, though (and apologies for sounding dismissive earlier!): Better support for pass would definitely be useful. If you're looking to set up secrets in a new repo with deploy-rs right now, I do recommend sops-nix because it's really quite nice & well-supported by all tools, including krops&deploy-rs.

[pinpox]

Thanks for the info, I'll look into it!

[bbigras]

It might be a good idea to rely on other tools. sops-nix seems pretty good. And there is (or will be?) also agenix.

[blaggacao]

agenix

• Encrypt with (r)age divnix/digga#37 (comment)
• Encrypt with (r)age divnix/digga#37 (comment) / https://christine.website/blog/nixos-encrypted-secrets-2021-01-20

[bbigras]

Does agenix support ssh keys yet? It was a deal breaker for me.

[blaggacao]

Looks like so: https://github.com/ryantm/agenix/blob/9eb981eeb552e0856cb562b7643b311933a0e992/pkgs/agenix.nix#L3 🚀

Christine's blog post does this nicely combine with a host metadata inventory file that basically holds all the cryptographic host identities (ssh / wireguard).

[bbigras]

Oh, sorry I misspoke. It supports ssh keys but not keys with passphrase. See ryantm/agenix#4

[wmertens]

Just chiming in to say that I don't think deploy-rs needs to solve this issue; sops-nix allows to solve it at the level of NixOS.

I just made a nice setup:

• I keep the SSH known_hosts file in my repo
• a script encrypts stdin for a given host + stores in predictable location under repo/secrets/$node/$name.sops
• extends the module a little:
  • reads the repo/secrets/ directory and populates the config.sops.secrets entries for that host
    • this auto-populates them on the server
  • extends the sops.secrets option to take an azure vault key name
• a script runs nix eval to figure out the secrets that don't have corresponding files yet, and
  • gets it from azure + encrypts it for the host
  • or generates a new one, stores on azure and encrypts it for the host
• a deploy wrapper runs that script

This is somewhat specific for our situation, but as you can see, deploy-rs would not really help here, it's an orthogonal problem.