SSO et identités (Kanidm)

Kanidm 🡕 est le fournisseur d’identité du réseau : une identité unique ouvre tous les services (SSO). Le service idm tourne sur le HCS (et, en option, en réplica dans chaque zone).

Identités et groupes

Comptes et groupes sont provisionnés dans Kanidm depuis etc/config.yaml :

users:
  alice:
    profile: "nix-admin"
    groups: ["idm-admins", "idm-devs", "global"]

Les groupes pilotent les accès aux services.
Deux groupes spéciaux : idm-admins (administration), idm-devs (développement).

Connecter un service (OIDC)

Les services compatibles OIDC sont reliés au SSO automatiquement : Kanidm provisionne un client OAuth2 par service, et son secret est géré par sops. Rien à configurer à la main.

Protéger un service sans OIDC

Un service sans authentification propre (page d’accueil, site statique) se protège en plaçant une mire de connexion Kanidm devant lui (oauth2-proxy + Caddy). Pour la page d’accueil, un réglage sur l’hôte passerelle (usr/machines/<passerelle>/) :

darkone.service.homepage.protect = true; # exige une session Kanidm

Option	Défaut	Effet
`protect`	`true`	Page d’accueil réservée aux utilisateurs Kanidm (groupe `users`)

Réplication multi-zone

Le mode est déduit de l’endroit où idm est déclaré :

idm sur le HCS seul → instance unique, pas de réplication.
idm sur une passerelle sans HCS → instance autonome dans la zone.
idm sur le HCS et des passerelles → réplication : le HCS fournit, chaque passerelle est un réplica en lecture seule.

Administration

L’administration se fait en ligne de commande sur le HCS :

just enter hcs
kanidm person credential create-reset-token <login> --name idm_admin

Voir Créer un compte utilisateur et Réinitialiser un mot de passe.

Mettre à jour Kanidm

Kanidm ne maintient qu’une seule version à la fois : une version atteint sa fin de vie 30 jours après la sortie de la suivante, et seule une montée de version en version est supportée. DNF épingle donc explicitement le paquet, dans dnf/modules/service/idm.nix :

services.kanidm.package = pkgs.kanidm_1_11.withSecretProvisioning;

L’évaluation prévient dès que la version épinglée est dépréciée :

kanidm 1.10 is deprecated and will reach end-of-life on 2026-08-31

Passée cette date, nixpkgs marque la version comme non maintenue et l’évaluation échoue. La montée est donc à planifier avant l’échéance.

Contrôle de compatibilité, sur le HCS, avant de toucher à la version :
Fenêtre de terminal
```
just enter hcs
sudo kanidmd domain upgrade-check -c /etc/kanidm/server.toml
```
Opération en lecture seule. Chaque item doit ressortir PASS ; un FAIL se corrige avant d’aller plus loin.
Copie à froid de la base, seul rollback réellement fiable :
Fenêtre de terminal
```
sudo systemctl stop kanidm
sudo install -d -o kanidm -g kanidm /var/lib/kanidm/pre-upgrade
sudo cp -a /var/lib/kanidm/kanidm.db* /var/lib/kanidm/pre-upgrade/
sudo kanidmd database backup /var/lib/kanidm/pre-upgrade/dump.json -c /etc/kanidm/server.toml
sudo chown -R kanidm:kanidm /var/lib/kanidm
sudo systemctl start kanidm
```
Copier le journal, pas seulement la base. SQLite ne fusionne pas toujours son journal d’écriture en fermant : un kanidm.db-wal de plusieurs Mo survit couramment à l’arrêt du service. Copier kanidm.db seul laisserait de côté les dernières transactions. Le * prend le triplet .db, .db-wal et .db-shm, qui ne vaut que pris ensemble.

Le chown final n’est pas optionnel : les deux commandes précédentes tournent en root et laisseraient sinon des fichiers que le service ne peut plus écrire.
Passer l’épingle à la version suivante, une seule à la fois, puis déployer le HCS.
Vérifier le service et la cohérence de la base :
Fenêtre de terminal
```
systemctl status kanidm
sudo kanidmd database verify -c /etc/kanidm/server.toml
```
Terminer par une vraie connexion OIDC sur un service du réseau.

En cas d’échec : remettre l’épingle sur la version précédente, restaurer le fichier .bak à la place de kanidm.db (service arrêté), redéployer.