Comparison of secret managing schemes: Difference between revisions

From NixOS Wiki
imported>Pacman99
No edit summary
imported>Pacman99
No edit summary
Line 67: Line 67:
| encrypted
| encrypted
| decryption with the ssh host key
| decryption with the ssh host key
|
| unencrypted in {{|ic|/run/secrets/...}}
| yes
| yes
| the underlying {{ic|age}} does not support {{ic|ssh-agent}}
| the underlying {{ic|age}} does not support {{ic|ssh-agent}}

Revision as of 00:17, 26 March 2021

In case this page is dificult to read with the default theme try the vector theme.

Introduction

Sometimes you need to use secrets in your system configuration. Those can range from user passwords and Wifi passwords over private keys (ssh, ssl, ...) to API tokens and similar things. Normally one would store this kind of information in files with restricted access writes (only readable by some Unix user) or even encrypt them on disk. Nix and NixOS store a lot of information in the world-readable Nix store where at least the former is not possible. People who track their configuration with Git (or use Flakes) might even want to store these secrets in the Git repository but still upload the repository somewhere.

In these cases it is necessary to think about a suitable scheme to manage the relevant secrets so that they are only readable by the right people or machines. This page tries to give an overview of different schemes that can be used and outlines the aims, requirements and implications of each.

Definitions

The properties of the different schemes that are listed in the table below are explained in detail here. You are welcome to add more schemes (rows) to the table; please try to fill in as many of the properties as you can.

scheme
the name of the scheme, if possible a link to the official website or source, maybe a short description
pre build
Where does the secret reside before the configuration is build? In a file, in a nix expression, in an external database (password manager)? Is it encrypted?
build time
what happens at build time, is the secret decrypted or encrypted, which master passwords, passphrases or helper programs are needed
in the store (on disk)
Is the data stored in /nix/store after the build? Is it encrypted. This has implications for reproducability. If a secret is not stored in the nix store it might be more difficult to recreate an old system configuration
system activation
what happens to the data at system activation, that is at boot time or when nixos-rebuild switch or --rollback is executed
runtime
where does the secret reside after system activation, is it encrypted, who can read it
"official" project
whether this is a published software project (maybe even actively developed) or just some notes in a forum or a blog entry

Comparison

Comparison of secret managing schemes
scheme pre build build time /nix/store (or on disk) system activation runtime "official" project notes
NixOps keys

(is there a better link to the docs that does not depend on a hydra build id?)

plain text in a nix expression no, stored outside of the store (TODO more info) unencrypted in /run/keys/..., the user has to run nixops

send-keys to create these files after a reboot

yes "out of band", secret management happens outside of nixos-rebuild
agenix encrypted with the users ssh key reencryption for the ssh host key encrypted decryption with the ssh host key ic|/run/secrets/...}} yes the underlying age does not support ssh-agent
sops-nix yes
krops yes
buildins.readfile

on discourse

no
buildins.exec

on discourse

no
Blog entry 1

based on age and the ssh host key of the target machine

plain text file (unencrypted), can be stored in git encryption encrypted, in the store decrypted by a systemd unit no, blog,

and config repository

Blog entry 2 no