Comparison of secret managing schemes: Difference between revisions

Some NixOS modules require the use of secret information to function correctly. This information can include user<ref>The <code>[http://search.nixos.org/options?show=users.users.%253Cname%253E.hashedPasswordFile <nowiki>users.users.<name>.hashedPasswordFile</nowiki>]</code> option.</ref> and Wi-Fi passwords<ref>The {{nixos:option|networking.wireless.secretsFile}} option.</ref>, cryptographic private keys<ref>The {{nixos:option|services.openssh.hostKeys}} option.</ref> and secret API tokens<ref>The {{nixos:option|services.mjolnir.accessTokenFile}} option. (among many others)</ref>, among many other examples of secret information. On a standard Linux system, one would store this kind of information in separate files with restricted access rights (only readable by some Unix user) or encrypt them on-disk.  

While this paradigm is still available to NixOS users, a Nix-managed system is in an unique position to leverage <b>secret managing schemes</b>: special software capable of deploying secret information securely. Instead of writing the secret information unencrypted to a NixOS configuration, the software described below can decrypt the relevant secrets and deploy them at various stages of the NixOS system deployment process. This advanced form of secrets configuration is even more important for NixOS configurations tracked with Git or [[Flakes]], as one will be able to store these encrypted secrets in the Git repository and still be able to upload the repository on the public Internet.

 

The most popular options for secrets management are [[Agenix]], [https://github.com/Mic92/sops-nix sops-nix] or the secrets management solution native to the deployment tool you chose. Below follows a more in-depth comparison including less well-known solutions.

The properties of the different schemes that are listed in the table below are explained in detail here.

: The name of the scheme; if possible also a link to the official website or source.

: Is the data stored in <code>/nix/store</code> after the build? Is it encrypted? This has implications for reproducibility: if a secret is not stored in the Nix store it might be more difficult to recreate an old system configuration.

: What happens to the data at system activation, that is, at boot time or when <code>nixos-rebuild switch</code> or <code>nixos-rebuild switch --rollback</code> is executed.

: Where does the secret reside after system activation? Is it encrypted? Who can read it?

: Whether this is a published software project (maybe even actively developed) or just usage notes in a forum or a blog entry.

|+ Comparison of secret managing schemes<ref>[https://discourse.nixos.org/t/comparison-of-different-key-secret-managing-schemes/12001/1 Comparison of different key/secret managing schemes] on the NixOS Discourse</ref>

! Scheme

! Pre-build

! Build time

! In the store

! System activation

! Runtime

! Encryption technology

! Usable project

! Templating support

! Additional notes

| [[Agenix]]

| Encrypted raw files, <code>agenix</code> CLI encrypts with the user and host ssh key

| N/A

| Decryption with the host SSH key.

| Unencrypted in <code>/run/secrets</code> or configured path.

| Uses <code>[https://github.com/FiloSottile/age age]</code> with SSH user and host keys; does not support <code>ssh-agent</code>.

| No

|-

| Decryption with the host SSH key.

| Use with <code>agenix</code>; provides more convenience.

| [https://github.com/yaxitech/ragenix ragenix]

| Encrypted raw files, <code>ragenix</code> CLI encrypts with the user and host SSH keys.

| Decryption with the host SSH key.

| Unencrypted in <code>/run/secrets</code> or configured path.

| Drop-in replacement of <code>agenix</code>, written in Rust and based on the <code>age</code> crate.

| Yes

| No

| Uses [https://www.passwordstore.org/ the password store] (aka <code>pass</code>) which uses GPG.

| Yes

| No

| [https://github.com/tweag/terraform-nixos terraform-nixos]

| Encrypted

| [https://github.com/brizzbuzz/opnix brizzbuzz/opnix]

| 1password

| Uses [https://www.passwordstore.org/ the password store] (aka <code>pass</code>) which uses GPG.

| <code>builtins.readfile</code>, <code>builtins.exec</code><ref>[https://discourse.nixos.org/t/using-an-external-secret-file-in-a-nix-sandboxed-build/3274 Using an external secret file in a Nix sandboxed build] on the NixOS Discourse</ref>

| <code>builtins.readfile</code> can read any file, <code>builtins.exec</code> can execute commands and thus query any kind of database or password manager.

| These functions return values in a Nix expression; it is up to the user what happens to these values in the NixOS configuration.

| See "build time"

| See "build time"

| These functions just read files or execute commands, they do not provide anything inherently "secure" or "cryptographic".

| No

| No

| The referenced NixOS Discourse discussion is about a signing key that is only needed during build time and should not be stored in the nix store at all.

! Pre-build