How to best support templating?

[wmertens]

Great project! :heart:

I'm using this to store a VPN secret, and the file that has the secret actually has a bunch of configuration in it that isn't secret, and it would be nicer to have it in the configuration in plaintext.

What would be a good way to generate the required secret config file from the given secret password? This would have to happen during activation after the secret is decrypted.

Could sops-nix support this directly? For example, would it be possible to support a configuration like this:

{
  sops.secrets.vpn.template = ''
    username=foo
    reconnect=always
    password=@SECRET@
  '';
}

(you only get the template result in the secrets dir, instead of the secret)

or perhaps with multiple secrets:

{
  sops.secrets.vpn = {
    secrets = [ "vpn-pass" "vpn-cert" ];
    template = ''
      username=foo
      reconnect=always
      password=@vpn-pass@
      cert=@vpn-cert@
    '';
    user = "vpn";
  };
}

(you get all secrets + template results in the secrets dir, they can't clash, and they can have their own permissions)

[Mic92]

I think you can combine sops-nix with https://github.com/polygon/scalpel to support this. It's currently not supported by sops-nix itself also it would be a good idea...

[sg-qwt]

Btw, the nixos-cn repo contains a VERY useful template module for sops-nix. It essentially swaps out template during post install stage. The docs is in Chinese, but you can get the gist of it by the sample provided in docs.

https://github.com/nixos-cn/flakes/tree/main/modules/sops

[wmertens]

@sg-qwt this is perfect! And Google translate handles it beautifully. It seems to me that this functionality should be in sops-nix proper @Mic92

[darkone23]

thanks @sg-qwt - pulled that template module into my project and using it successfully to template stuff... woohoo!

another :+1: to adding this functionality to the main library - thanks for creating it @Mic92 !

[shajra]

I'm coming into this kind of fresh... but unless I'm mistaken, it seems like the nixos-cn code has been ported over, but only to the system-level module, not the home-manager one.

To save my time retracing tracks, could someone share their thoughts on the challenges getting templates working with home-manager?

To start, I feel like at the system-level, decrypting secrets is part of the boot-up process. Whereas with home-manager, you kind of opt-in by turning on the service explicitly. If so, I guess that makes a little bit of a challenge for automation.

But it feels surmountable, right?

[Mic92]

There shouldn't be any hurdle to port the template system from the nixos module to the home-manager module. There is also a script section: https://github.com/Mic92/sops-nix/blob/4a330ead6a990365c9bb48f30523ac048fb6d8ae/modules/home-manager/sops.nix#L89 where the same code that runs in the nixos activation script could be placed.

[shajra]

@Mic92 if I'm reading this code right, it seems like the NixOS side does secrets management as part of an activation script. But the Home Manager side seems to do secrets management as part of a script run as a systemd service.

When introducing templates, I think I would prefer to have secrets deployed as an activation script. Sometimes, I can have configuration files with secrets that are consumed by CLI tools. It's not ideal, but it's hard to control every little application that's out there. Having to kick off a systemd service, just to get secrets working for CLI tools seems a bit obtuse (in the case where there's no services consuming the secrets).

First off, am I understanding this code correctly. Secondly, is there any known problem with deploying secrets on the Home Manager side as an activation script instead of a script run by a base-dependency of systemd services? I think this might move towards stronger alignment between the NixOS side and the Home Manager side.

[shajra]

On the other hand... one benefit of having a systemd unit handle secrets deployment is that it can nuke the files when the service shuts down. Has there been any discussion about cleanup? When doing this stuff with activation scripts, these secrets just persist when deployed, right? Could that lead to a little bit of leakage if there's no cleanup?

[Mic92]

I guess the home-manager module could also use an activation script instead. I don't recall why @dasJ used a systemd service instead. If the secrets are unpacked to XDG_RUNTIME_DIR which is located on a tmpfs ideally than it should be cleared out after logout in any case.

[dasJ]

Because NixOS has no concept of user activation scripts ;) home manager may (I'm unsure) but everyone seems to hate the concept as far as I'm aware

[Mic92]

I see, so the issue would be that it won't run after login because the home-manager activation script is never run.

[wmertens]

Wouldn't it be possible to define a user unit that does activation? Without any extra support from NixOS?

https://wiki.archlinux.org/title/systemd/User

[pogobanane]

let me mention #299 here for completeness