Comparison of secret managing schemes: Difference between revisions
imported>Lucc |
imported>Pacman99 No edit summary |
||
| Line 3: | Line 3: | ||
== Introduction == | == Introduction == | ||
Sometimes you need to use secrets in your system configuration. | Sometimes you need to use secrets in your system configuration. Those can | ||
range from user passwords and Wifi passwords over private keys (ssh, ssl, ...) | range from user passwords and Wifi passwords over private keys (ssh, ssl, ...) | ||
to API tokens and similar things. | 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 | information in files with restricted access writes (only readable by some Unix | ||
user) or even encrypt them on disk. | 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 | in the world-readable Nix store where at least the former is not possible. People who track | ||
their configuration with Git (or | their configuration with Git (or use [[Flakes]]) might even want to store | ||
these secrets in the Git repository but still upload the repository somewhere. | 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 | 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 | relevant secrets so that they are only readable by the right people or | ||
machines. | machines. This page tries to give an overview of different schemes that can | ||
be used and outlines the aims, requirements and implications of each. | be used and outlines the aims, requirements and implications of each. | ||