1
1
Fork 0
mirror of https://github.com/NixOS/nix.git synced 2025-12-03 23:51:00 +01:00

docs: avoid secrets in the nix store

I think this is noncontroversial / common knowledge, but I didn't
see it described anywhere authoratively yet.
This commit is contained in:
Arnout Engelen 2025-11-13 13:04:12 +01:00
parent 3645671570
commit 91cdd88714
No known key found for this signature in database
GPG key ID: 061107B0F74A6DAA
2 changed files with 21 additions and 0 deletions

View file

@ -29,6 +29,7 @@
- [Build Trace](store/build-trace.md) - [Build Trace](store/build-trace.md)
- [Derivation Resolution](store/resolution.md) - [Derivation Resolution](store/resolution.md)
- [Building](store/building.md) - [Building](store/building.md)
- [Secrets](store/secrets.md)
- [Store Types](store/types/index.md) - [Store Types](store/types/index.md)
{{#include ./store/types/SUMMARY.md}} {{#include ./store/types/SUMMARY.md}}
- [Appendix: Math notation](store/math-notation.md) - [Appendix: Math notation](store/math-notation.md)

View file

@ -0,0 +1,20 @@
# Secrets
The store is readable to all users on the system. For this reason, it
is generally discouraged to allow secrets to make it into the store.
Even on a single-user system, separate system users isolate services
from each other and having secrets that all local users can read
weakens that isolation. When using external store caches the secrets
may end up there, and on multi-user systems the secrets will be
available to all those users.
Organize your derivations so that secrets are read from the filesystem
(with appropriate access controls) at run time. Place the secrets on
the filesystem manually or use a scheme that includes the secret in
the store in encrypted form, and decrypts it adding the relevant
access control on system activation.
Several such schemes for NixOS can in the
[comparison of secret managing schemes] on the wiki.
[comparison of secret managing schemes]: https://wiki.nixos.org/wiki/Comparison_of_secret_managing_schemes