Les secrets (sops-nix)

Tous les secrets du réseau (mots de passe, clés, jetons) vivent chiffrés dans un seul fichier, géré par sops-nix 🡕. Il est versionné dans git sous forme chiffrée ; seuls les porteurs d’une clé peuvent le déchiffrer.

# usr/secrets/secrets.yaml (chiffré au repos)
default-password-hash: ...
user:
  alice:
    password-hash: ...

Les deux clés

Le déchiffrement repose sur deux clés age 🡕 :

Clé	Où	Rôle
Clé admin	~/.config/sops/age/keys.txt	Éditer les secrets depuis le poste admin
Clé d’infra	/etc/sops/age/infra.key	Déchiffrer sur chaque hôte au déploiement

• La clé admin dérive de votre clé SSH (~/.ssh/id_ed25519, via ssh-to-age).
• La clé d’infra est générée une fois, puis poussée sur chaque hôte.
• Les destinataires sont listés dans usr/secrets/.sops.yaml (admin + infra).

Ne jamais committer une clé privée

La clé d’infra vit hors du dépôt (/etc/sops/age/). Le .gitignore de usr/secrets/ exclut déjà *.key. Ne la copiez jamais dans le dépôt.

Initialiser (poste admin)

Une seule commande prépare tout l’appareillage de secrets :

just configure-admin-host

Elle est idempotente et crée, au besoin :

• la clé SSH du déployeur (nix) ;
• un mot de passe aléatoire, connu de personne, pour le compte nix : il n’entre que par sa clé ;
• la clé admin (depuis la clé SSH) et la clé d’infra (age-keygen) ;
• le fichier .sops.yaml (destinataires) ;
• l’empreinte du mot de passe par défaut (just passwd-default) ;
• la clé de signature du cache binaire Harmonia ;
• tous les secrets internes des services déclarés (voir plus bas).

À relancer après avoir activé un service

La commande lit les secrets que réclame chaque hôte du parc et crée ceux qui manquent. Activer un nouveau service, ajouter un hôte ou une zone : relancez just configure-admin-host, il ne complètera que ce qui manque.

Détail du parcours

Cette étape fait partie de l’installation initiale.

Secrets internes et secrets externes

Le framework range chaque secret dans l’une de deux familles. La liste de référence vit dans dnf/lib/secrets.nix ; l’autorité sur ce qui est réclamé reste chaque hôte du parc.

Internes — la valeur n’a de sens que pour les machines, personne ne la retient. just configure-admin-host les tire au hasard, une bonne fois :

Famille	Exemples
Clients OAuth2 Kanidm	oidc-secret-<client>, cookie oauth2-proxy
Sauvegarde	restic-password-<zone>, restic/<hôte>/rest-password
Matrix	secrets MAS, livekit-secret, jetons des ponts, turn-secret
Identités	mots de passe de secours Kanidm, paire TLS interne
Services	AdGuard Home, Nextcloud, Grafana, SearXNG, Vaultwarden, Garage, MinIO…

Externes — la valeur vient d’ailleurs, DNF ne peut pas l’inventer :

Famille	Origine
Mots de passe de comptes	choisis par l’humain (just passwd)
smtp/password (avec network.smtp), wifi-password-<zone>	fournisseur, box, opérateur
mautrix-telegram-api-*	my.telegram.org
luks-passphrase, yubikey/…	frappée au démarrage, ou dérivée de la clé physique
alertmanager-matrix-*	compte créé sur le serveur (just configure-alert-bot)

Un secret interne peut quand même servir à un humain

Mot de passe admin d’AdGuard Home (adguardhome-admin-password, dont seule l’empreinte part sur les passerelles), comptes de secours Kanidm, jeton Vaultwarden : les relire avec just sops.

Rien n’est jamais écrasé

La génération ne crée que ce qui manque. Faire tourner un secret reste un geste délibéré : le supprimer avec just sops, puis relancer just configure-admin-host.

Ce que DNF ne connaît pas

Un secret manquant que le registre ne sait pas classer est signalé à chaque passage. Renseignez-le avec just sops — ou, s’il s’agit d’un module du framework, ajoutez sa règle dans dnf/lib/secrets.nix.

Gérer les mots de passe

Commande	Effet
just passwd-default	Enregistre le mot de passe par défaut du parc (empreinte seule)
just passwd <user>	Définit le mot de passe d’un utilisateur
just configure-admin-host	Génère les secrets internes manquants (OIDC, sauvegarde, jetons de service…)
just yubikey <user>	Enrôle une YubiKey (secret LUKS dérivé + luks-passphrase)
just luks <hôte>	Provisionne le chiffrement disque (passphrases partagée + par hôte)
just sops	Édite le fichier de secrets à la main ($EDITOR)

Après un changement, déployez pour le propager :

just passwd alice
just apply @user-alice     # déploie la nouvelle empreinte

Empreintes, jamais le clair

Les mots de passe de comptes sont stockés hachés (password-hash). Le clair n’est jamais déployé sur les hôtes.

Le mot de passe par défaut ne configure aucun compte

just passwd-default ne fait qu’enregistrer l’empreinte du mot de passe de référence du parc, et amorce le fichier sops. Un compte n’ouvre de session qu’après just passwd <login>. Le faire tourner impose donc de repasser sur chaque compte concerné.

Désactiver sops désactive les mots de passe

darkone.system.core.enableSops = false supprime les secrets user/<login>/password-hash, seule source de mot de passe du framework : les comptes déclarés seraient créés sans aucune authentification. L’évaluation s’arrête donc avec un message nommant l’option à rétablir. Pour un hôte volontairement sans comptes DNF, poser aussi darkone.user.build.enable = false.

YubiKey : registre public + secrets

L’enrôlement YubiKey pose ses credentials publics dans usr/secrets/yubikeys.json (versionné en clair, inutilisable sans la clé physique) et ses secrets (yubikey/<user>/<clé>/luks-secret, luks-passphrase) dans le fichier sops. Voir Authentification forte.

Pousser la clé sur un hôte

Un hôte ne déchiffre les secrets qu’avec la clé d’infra. Elle est posée automatiquement par just configure <host>, ou à la main :

just push-key <host>      # copie /etc/sops/age/infra.key sur l'hôte

Rarement utile

push-key est déjà intégré à just install (et just configure) : en pratique, vous ne devriez pas avoir à l’appeler vous-même.

Faire tourner la clé d’infra

La rotation remplace la clé d’infra sur tout le parc, en trois temps vérifiés :

Finalize seulement quand tout le parc est à jour

finalize supprime l’ancienne clé. Si un hôte n’a pas encore reçu la nouvelle (rotate push-keys + just apply), il devient impossible à déchiffrer, donc inaccessible au déploiement. N’exécutez finalize qu’après avoir confirmé que tous les hôtes portent la nouvelle clé.

1. Introduire la nouvelle clé

   just rotate init        # nouvelle clé + ré-chiffrement (ancienne + nouvelle)

2. Diffuser sur tous les hôtes

   just rotate push-keys   # chaque hôte reçoit les deux clés
   just apply '*'

3. Finaliser

   just rotate finalize    # abandonne l'ancienne clé (après vérification)
   just apply '*'

Ordre imposé

La présence de /etc/sops/age/infra.key.old signale une rotation en cours. Terminez toujours par finalize : tant qu’elle n’est pas faite, les hôtes portent les deux clés.

FAQ

Jeton Vaultwarden haché (Argon2) ?

just invite se connecte seul au panneau /admin avec le jeton en clair de vaultwarden-admin-token. Une empreinte Argon2 posée à la main l’oblige à demander le jeton ; just configure-admin-host le signale.

Pour migrer : supprimer l’entrée avec just sops, relancer just configure-admin-host, puis just apply hcs. Vaultwarden redémarre avec le nouveau jeton. Le panneau reste protégé par le réseau : il ne répond que depuis le LAN et le tailnet.

Nouvelle machine d’admin, projet existant ?

Les secrets du projet sont chiffrés pour les clés de l’ancienne machine d’admin. just configure-admin-host refuse donc d’en créer de nouvelles : restaurez d’abord /home/nix/.ssh/id_ed25519 et /etc/sops/age/infra.key (propriété de nix, mode 600).

Préparer une machine sans compte nix ?

just bootstrap-keys crée les clés et le squelette sops sous une racine donnée, par exemple /mnt depuis l’installateur, avec les identifiants que NixOS donnera au compte nix. Voir le Justfile.