Difference between revisions of "Comparison of secret managing schemes"

From NixOS Wiki
Jump to: navigation, search
(put in some info)
Line 1: Line 1:
 
== Introduction ==
 
== Introduction ==
Sometimes you need to use secrets in you 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 Nix store where at least the former is not possible. People who track their configuration with Git (or even 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.
+
Sometimes you need to use secrets in you 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 Nix store where at least the former is not possible. People who track
 +
their configuration with Git (or even 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 ==
 
== 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.
+
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
 +
; "official" project
 +
: whether this is a software project published (maybe even actively developed) or just some notes in a forum or a blog entry
  
TODO (when the table takes shape)
+
TODO: more (when the table takes shape)
  
 
== Comparison ==
 
== Comparison ==
Line 15: Line 33:
 
|+ Comparison of secret managing schemes
 
|+ Comparison of secret managing schemes
 
! scheme
 
! scheme
! stored in git
+
! pre build
! encrypted (until)
+
! build time
! in the store
+
! {{ic|/nix/store}} (or on disk)
 +
! system activation
 +
! runtime
 
! "official" project
 
! "official" project
 
! notes
 
! notes
Line 23: Line 43:
 
| [https://hydra.nixos.org/build/115931128/download/1/manual/manual.html#idm140737322649152 NixOps keys]
 
| [https://hydra.nixos.org/build/115931128/download/1/manual/manual.html#idm140737322649152 NixOps keys]
 
(is there a better link to the docs that does not depend on a hydra build id?)
 
(is there a better link to the docs that does not depend on a hydra build id?)
| yes (in a nix expression)
+
| plain text in a nix expression
| no
+
|
| no
+
| no, stored outside of the store (TODO more info)
 +
|
 +
| unencrypted in {{ic|/run/keys/...}}, the user has to run {{ic|nixops
 +
send-keys}} to create these files after a reboot
 
| yes
 
| yes
|
+
| "out of band", secret management happens outside of {{ic|nixos-rebuild}}
 
|-
 
|-
 
| [https://github.com/ryantm/agenix agenix]
 
| [https://github.com/ryantm/agenix agenix]
 +
|
 +
|
 +
|
 +
|
 +
|
 +
| yes
 +
|
 
|-
 
|-
 
| [https://github.com/Mic92/sops-nix sops-nix]
 
| [https://github.com/Mic92/sops-nix sops-nix]
 +
|
 +
|
 +
|
 +
|
 +
|
 +
| yes
 +
|
 
|-
 
|-
 
| [https://github.com/krebs/krops krops]
 
| [https://github.com/krebs/krops krops]
 +
|
 +
|
 +
|
 +
|
 +
|
 +
| yes
 +
|
 
|-
 
|-
 
| {{ic|buildins.readfile}}
 
| {{ic|buildins.readfile}}
 
[https://discourse.nixos.org/t/using-an-external-secret-file-in-a-nix-sandboxed-build/3274 on discourse]
 
[https://discourse.nixos.org/t/using-an-external-secret-file-in-a-nix-sandboxed-build/3274 on discourse]
 +
|
 +
|
 +
|
 +
|
 +
|
 +
| no
 +
|
 
|-
 
|-
 
| {{ic|buildins.exec}}
 
| {{ic|buildins.exec}}
 
[https://discourse.nixos.org/t/using-an-external-secret-file-in-a-nix-sandboxed-build/3274 on discourse]
 
[https://discourse.nixos.org/t/using-an-external-secret-file-in-a-nix-sandboxed-build/3274 on discourse]
 +
|
 +
|
 +
|
 +
|
 +
|
 +
| no
 +
|
 
|-
 
|-
 
| [https://christine.website/blog/nixos-encrypted-secrets-2021-01-20 Blog entry 1]
 
| [https://christine.website/blog/nixos-encrypted-secrets-2021-01-20 Blog entry 1]
 +
based on [https://github.com/FiloSottile/age 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, [https://christine.website/blog/nixos-encrypted-secrets-2021-01-20 blog],
 +
and [https://github.com/Xe/nixos-configs/blob/master/common/crypto/default.nix config repository]
 +
|
 
|-
 
|-
 
| [https://elvishjerricco.github.io/2018/06/24/secure-declarative-key-management.html Blog entry 2]
 
| [https://elvishjerricco.github.io/2018/06/24/secure-declarative-key-management.html Blog entry 2]
 +
|
 +
|
 +
|
 +
|
 +
|
 +
| no
 +
|
 
|}
 
|}

Revision as of 21:20, 25 March 2021

Introduction

Sometimes you need to use secrets in you 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 Nix store where at least the former is not possible. People who track their configuration with Git (or even 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
"official" project
whether this is a software project published (maybe even actively developed) or just some notes in a forum or a blog entry

TODO: more (when the table takes shape)

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 yes
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