I’ve recently evaluated sops-nix and, although I appreciate that managing keys is hard and ssh keys are pretty much the only thing anyone ever manages successfully, and that furthermore I am the only person in the world who likes gpg, I really don’t think reusing the ssh host key as the root of all trust is the right call. It violates principles around key reuse, which at best is sketchy and at worst may lead to vulnerabilities.
sops-nix is a pragmatic upgrade over storing plain text secrets in the git repo. It’s pretty easy to use and doesn’t require more infrastructure. There is a bit more work to enrol new host keys.
For highly sensitive projects you might want to use some sort of KMS, deploy Vault or something like that, but then it either only works in one cloud, or requires more infrastructure.
I have been studying the problem and reached the conclusion that any management of build-time secrets that meets my needs inherently requires impure evaluation. This is pretty unfortunate because of how flakes turn on pure evaluation by default… I’ve been weighing whether to propose a small extension to the semantics, but people let me know about some existing features that haven’t yet been leveraged for secret management, so in my Copious Free Time*, I’ve been figuring out whether there’s a good approach that doesn’t require additional changes to the language or CLI tools.
[*] Copious Free Time is a fictional character from oral traditions, and is not subject to copyright. Therefore I can make no guarantees about it actually existing.
I tried using sops but couldn’t understand the docs. I must be daft because I still cannot wrap my head around how it works after reading this article. Nothing explains how the encryption/decryption actually happens.
Upon exiting SOPS will then encrypt the contents using each of the keys in the key group as defined by the .sops.yaml file.
For that sops-nix provides a NixOS module which will take care of decrypting secrets on startup based on the host ssh key
The host ssh private key? Why would the host have a private ssh key being used for decryption? Do I have to have a copy of that locally when encrypting the yaml files?
As I understand, the basic idea is that you have a file containing encrypted secrets. SOPS is a shim layer between your editor and the encrypted file: it opens and parses the file, decrypts the values, and opens the editor on the decrypted file. When the editor exits, it parses the modified file, encrypts the values, and saves that. (Note how SOPS only supports a specific list of structured file formats.) Based on the SOPS docs, it looks like the tool also supports performing those middleman operations via CLI invocation, which would be how you can build a NixOS module that does those operations on secret files.
The SOPS README has different sections for various secret key formats, like AWS or SSH, and the configuration for those seems to rely on environment variables. So I suspect the “how does *cryption happen” question is answered by which environment variables are set, which indicates to SOPS where to look and what to do with it.
I have a subfolder in my NixOS config called confidential, with various keys and such. Only readable by root and excluded from all repos.
Works, but I should probably upgrade to something like this.
I’ve recently evaluated sops-nix and, although I appreciate that managing keys is hard and ssh keys are pretty much the only thing anyone ever manages successfully, and that furthermore I am the only person in the world who likes gpg, I really don’t think reusing the ssh host key as the root of all trust is the right call. It violates principles around key reuse, which at best is sketchy and at worst may lead to vulnerabilities.
Sounds good, but what alternative do you propose?
sops-nix is a pragmatic upgrade over storing plain text secrets in the git repo. It’s pretty easy to use and doesn’t require more infrastructure. There is a bit more work to enrol new host keys.
For highly sensitive projects you might want to use some sort of KMS, deploy Vault or something like that, but then it either only works in one cloud, or requires more infrastructure.
I have been studying the problem and reached the conclusion that any management of build-time secrets that meets my needs inherently requires impure evaluation. This is pretty unfortunate because of how flakes turn on pure evaluation by default… I’ve been weighing whether to propose a small extension to the semantics, but people let me know about some existing features that haven’t yet been leveraged for secret management, so in my Copious Free Time*, I’ve been figuring out whether there’s a good approach that doesn’t require additional changes to the language or CLI tools.
[*] Copious Free Time is a fictional character from oral traditions, and is not subject to copyright. Therefore I can make no guarantees about it actually existing.
(edit: syntax)
[Comment removed by author]
I tried using sops but couldn’t understand the docs. I must be daft because I still cannot wrap my head around how it works after reading this article. Nothing explains how the encryption/decryption actually happens.
The host ssh private key? Why would the host have a private ssh key being used for decryption? Do I have to have a copy of that locally when encrypting the yaml files?
As I understand, the basic idea is that you have a file containing encrypted secrets. SOPS is a shim layer between your editor and the encrypted file: it opens and parses the file, decrypts the values, and opens the editor on the decrypted file. When the editor exits, it parses the modified file, encrypts the values, and saves that. (Note how SOPS only supports a specific list of structured file formats.) Based on the SOPS docs, it looks like the tool also supports performing those middleman operations via CLI invocation, which would be how you can build a NixOS module that does those operations on secret files.
The SOPS README has different sections for various secret key formats, like AWS or SSH, and the configuration for those seems to rely on environment variables. So I suspect the “how does *cryption happen” question is answered by which environment variables are set, which indicates to SOPS where to look and what to do with it.
sops supports a few different key formats. Since hosts tend to have ssh daemons on them, using the ssh private key to decrypt its secrets is handy.
Just the public key.
I have a subfolder in my NixOS config called
confidential, with various keys and such. Only readable by root and excluded from all repos. Works, but I should probably upgrade to something like this.Doesn’t that end up in /nix/store then, which is readable by everybody?
Ohh, you are right. So I definetly should to this workflow then…