mirror of https://gitlab.crans.org/nounous/nixos
Ajout README.md secrets
parent
9422c2fd58
commit
d966a21c4f
|
@ -4,7 +4,7 @@ keys:
|
|||
- &redite age1utlywxylme0z3jenv4uz8ftcwteg9877y3zf46fu7zwjjwa05g7q88w8t0
|
||||
- &two age1zlpu6qum5xcl07hnsndp78tllqph5jz7q8fr5ntxr88202xq9u9s9r2y7x
|
||||
|
||||
# Nounous keys.
|
||||
# Nounou keys.
|
||||
- &_aeltheos 0xDF6D6CE9E95E26E8
|
||||
- &_pigeonmoelleux 0xFA47BDA260489ADA
|
||||
|
||||
|
@ -20,7 +20,7 @@ creation_rules:
|
|||
- *redite
|
||||
- *two
|
||||
|
||||
# Secrets for neo
|
||||
# Secrets for neo.
|
||||
- path_regex: secrets/neo.yaml
|
||||
key_groups:
|
||||
- pgp:
|
||||
|
|
|
@ -57,7 +57,7 @@ Il est important de noter que **`/nix/store` est un dossier monté en lecture se
|
|||
|
||||
### Flakes
|
||||
|
||||
Le fichier [`flake.nix`](flake.nix) dénote de tous les autres fichiers de cette configuration : celui-ci est une `flake`, à savoir l'unité de permettant de packager du code `nix` de manière reproducible. Plus simplement, dans notre cas, cette `flake` contient toutes les sources utilisées dans la configuration pour pouvoir être évaluée, ainsi que toutes les sorties, à savoir les configurations de toutes les machines, ainsi que les shells de développement (voir [la partie sur les `devshells`](TODO)).
|
||||
Le fichier [`flake.nix`](flake.nix) dénote de tous les autres fichiers de cette configuration : celui-ci est une `flake`, à savoir l'unité de permettant de packager du code `nix` de manière reproducible. Plus simplement, dans notre cas, cette `flake` contient toutes les sources utilisées dans la configuration pour pouvoir être évaluée, ainsi que toutes les sorties, à savoir les configurations de toutes les machines, ainsi que les shells de développement (voir [la partie sur les `devshells`](#devshells)).
|
||||
|
||||
## Rôles des fichiers et sous-dossiers
|
||||
|
||||
|
@ -79,11 +79,11 @@ Le dossier [`modules`](modules) contient l'ensemble des options qui peuvent êtr
|
|||
|
||||
### Devshells
|
||||
|
||||
Le dossier [`devshells`](devshells) contient des environnements de travails pouvant être utilisés par tout utilisateur. Ceux-ci permettent d'ajouter temporairement des paquets à l'environnement de travail (dont le shell bash ou équivalent), permettant ainsi d'avoir facilement (voir [la partie sur les commandes liées aux devshells](TODO)) tous les outils nécessaires au développement/débuggage. Vous pouvez voir plus de détails dans [`devshells/README.md`](devshells/README.md).
|
||||
Le dossier [`devshells`](devshells) contient des environnements de travails pouvant être utilisés par tout utilisateurice. Ceux-ci permettent d'ajouter temporairement des paquets à l'environnement de travail (dont le shell bash ou équivalent), permettant ainsi d'avoir facilement (voir [la partie sur les commandes liées aux devshells](#commandes-pour-les-devshells)) tous les outils nécessaires au développement/débuggage. Vous pouvez voir plus de détails dans [`devshells/README.md`](devshells/README.md).
|
||||
|
||||
## Commandes utiles
|
||||
|
||||
Pour toutes les commandes présentées, on débutera la ligne de commande par `$` si tout utilisateur peut l'exécuter, et `#` s'il faut les droits super-utilisateur.
|
||||
Pour toutes les commandes présentées, on débutera la ligne de commande par `$` si tout utilisateurice peut l'exécuter, et `#` s'il faut les droits super-user.
|
||||
|
||||
### Commandes pour les flakes
|
||||
|
||||
|
@ -140,7 +140,7 @@ Pour toutes les commandes présentées, on débutera la ligne de commande par `$
|
|||
- Supprimer toutes les objets non atteignables dans le Nix Store
|
||||
|
||||
```
|
||||
# nix-collect-garbage
|
||||
# nix-collect-garbage -d
|
||||
```
|
||||
|
||||
- Optimiser les liens symboliques dans le Nix Store (permet de gagner de l'espace de stockage)
|
||||
|
|
|
@ -56,5 +56,5 @@ Voici la liste des étapes à suivre pour ajouter une nouvelle machine virtuelle
|
|||
|
||||
# Mettez un mot de passe quelconque pour le super utilisateur, il sera remplacé dans tous les cas.
|
||||
|
||||
# Vous pouvez maintenant redémarrer la VM et vous ssh dessus en tant que votre utilisateur _user.
|
||||
# Vous pouvez maintenant redémarrer la VM et vous ssh dessus en tant que votre _user.
|
||||
```
|
||||
|
|
|
@ -28,4 +28,4 @@ Le fichier [`sops.nix`](sops.nix) déclare l'utilisation de `sops` dans la confi
|
|||
|
||||
## `users.nix`
|
||||
|
||||
Le fichier [`users.nix`](users.nix) configure les `_users` à partir du LDAP d'administration, et configure les droits pour que les `_nounou` aient les accès `sudo`. Il configure également l'utilisateur `root` en lui donnant son mot de passe haché à travers un fichier `sops`.
|
||||
Le fichier [`users.nix`](users.nix) configure les `_users` à partir du LDAP d'administration, et configure les droits pour que les `_nounou` aient les accès `sudo`. Il configure également le user `root` en lui donnant son mot de passe haché à travers un fichier `sops`.
|
||||
|
|
|
@ -1 +1,43 @@
|
|||
# Secrets
|
||||
|
||||
## Introduction
|
||||
|
||||
La gestion des secrets sur NixOS peut se révéler complexe : comme expliquée dans [cette section du `README.md` racine](../README.md#nix-store), aucun secret ne peut apparaître dans le Nix Store. Il faut donc pouvoir charger les secrets dans des fichiers chiffrés qui seront déchiffrés à la reconstruction, sans être pour autant écrits dans le Nix Store. Deux logiciels usuels permettent de faire cela : [`agenix`](https://github.com/ryantm/agenix) et [`sops-nix`](https://github.com/Mic92/sops-nix). Étant donné que `agenix` ne permet pas d'utiliser des clefs GPG, le choix a été fait d'utiliser `sops-nix`.
|
||||
|
||||
## Sops-nix
|
||||
|
||||
On ne présentera pas ici tout les détails sur le fonctionnement de `sops-nix`, vous pouvez allez voir [cette section](https://github.com/Mic92/sops-nix?tab=readme-ov-file#usage-example) du `README.md` officiel.
|
||||
|
||||
### Clefs de chiffrement/déchiffrement
|
||||
|
||||
La première chose qu'il faut déterminer pour gérer les serets avec `sops-nix` est la gestion des clefs de chiffrement et de déchiffrement. Celles-ci sont de natures différentes : on utilisera des clefs SSH pour les machines et des clefs GPG pour les nounous. Dans les deux cas, on trouve les clefs publiques pour le chiffrement et les clefs privées pour le déchiffrement. La liste des clefs publiques est décrite dans la section `keys` du fichier [`../.sops.yaml`](../.sops.yaml).
|
||||
|
||||
### Secrets
|
||||
|
||||
Il faut ensuite chiffrer les secrets que l'on souhaite déclarer. Ces secrets sont décrits dans les différents fichiers YAML dans ce dossier. Chaque fichier n'a qu'une liste prédéfinie de clefs qui ont le droit de le déchiffrer, ce qui fait que toutes les machines n'ont pas accès à tous les secrets, mais seulement à ceux qui leur sont nécessaire. La liste des clefs utilisable pour chaque fichier se trouve dans la partie `creation_rules` du fichier [`../.sops.yaml`](../.sops.yaml). Après reconstruction de la configuration, les secrets sont situés dans le dossier `/run/secrets/`, qui n'est pas lisible par les _users, mais seulement par root. Chaque secret possède de plus un user et un groupe propriétaires qui ont les droits de lecture, ce qui peut être utile pour la gestion des secrets pour des services en particulier.
|
||||
|
||||
### Utilisation des secrets
|
||||
|
||||
Pour utiliser des secrets gérés par `sops-nix`, deux étapes sont nécessaires :
|
||||
- déclarer l'existence du fichier contenant le secret par `sops.secrets.<name>.sopsFile` ;
|
||||
- utiliser le fichier contenant le secret par `config.sops.secrets.<name>.path`.
|
||||
|
||||
Vous pouvez voir un exemple d'utilisation de tels secrets dans le fichier [`../modules/crans/users.nix`](../modules/crans/users.nix).
|
||||
|
||||
**Attention** : n'utilisez jamais de secret avec de fichier lisant le contenu du fichier pour l'écrire dans la configuration ! Cela fait perdre tout l'intérêt de l'utilisation de `sops`. Ainsi, il ne faut en aucun cas utiliser les fonctions `lib.readFile`, `lib.fileContents`, ... en combinaison de fichiers contenant des secrets.
|
||||
|
||||
### Commandes utiles
|
||||
|
||||
Vous devez avoir l'exécutable `sops` dans votre shell. Vous pouvez pour cela utiliser le [devshell](../devshells/README.md) par défaut avec la commande `nix develop` à la racine du projet.
|
||||
|
||||
- Mise à jour d'un fichier après changement des clefs :
|
||||
|
||||
```bash
|
||||
$ sops updatekeys [file]
|
||||
```
|
||||
|
||||
- Écriture d'un fichier chiffré :
|
||||
|
||||
```bash
|
||||
$ sops [file]
|
||||
```
|
||||
|
|
Loading…
Reference in New Issue