Add option for choosing which activation method to use #39
Conversation
| default = "script"; | ||
| description = '' | ||
| Which method to use for setting up secrets. Use `script` for an | ||
| activation script, and `systemd` for a systemd unit. |
There was a problem hiding this comment.
I think systemd is the way to go to use all features of sops-nix. I am thinking about deprecating the activation script method.
There was a problem hiding this comment.
Should I change this PR to reflect this? I'd be happy to do it.
There was a problem hiding this comment.
I hope I get to hack next weekend again on sops-nix: systemd/systemd#16568 (comment)
I prepared systemd socket activation and with this PR systemd/systemd#17510 I should be able to implement it properly and ready for networked KMS.
There was a problem hiding this comment.
To be more explicit with socket-based secret description it is easier to make systemd wait for secrets to become available without having to specify explicit dependencies. This was my major concern with having sops-nix running as a systemd service instead of activation script. I hope to be able to implement this soonish.
|
Hi @Mic92 👋 Sorry to pull up an old thread but...
Seeing as this PR was never closed is there still any interest in switching to a |
|
I have a particular use case where if sops-nix were to switch to a systemd service, it would open up secrets usage for short lived systems. Right now, sops-nix assumes GPG/age/ssh keys and it requires that key material exist and a deploy/nixos-rebuild. sops, if using AWS KMS (or any other KMS), will decrypt without that material at run time if roles and access to the correct KMS key is granted. I'd be happy to work a PR if this functionality is thought useful to the project. |
|
I'm interested in this in particular because it would allow me to use my machine's TPM as a root of trust, rather than my host SSH key. |
|
What's the current status of the pr? |
I just tested this on my machine and it seems to perform fine. The default behavior is set to the "old" way, so it's not a breaking change for existing users. Opting-in should be as simple as
sops.activationMethod = "systemd";I used an enum for now, but the alternative would be to use a boolean, ie.
useSystemd. I'm happy to change it.