Introduction

Bienvenue sur la documentation de l'infrastructure d'AliENS. Cette documentation est encore en construction. Vous pouvez chercher les sujets qui vous intéressent dans le sommaire.

Services hébergés sur « Protomolecule »

AliENS héberge sur son infrastructure différents services informatiques.

Le fichier présente un état des lieux des services hébergés, détaille leur intégration au sein de notre infrastructure ainsi la procédure administrative génerale afin d'héberger un nouveau service.

Le dossier doc/services/ contient aussi des documentations spécifiques pour certains services.

En pratique, les utilisateurices cibles des services d'AliENS sont toutes les personnes physiques (étudiant·es, personnels, ...) ou morales (associations) autour de la communauté de l'ENS de Lyon.

Définition d'un service informatique

Un service informatique est une application s'exécutant sur un serveur dont le but est de mettre à disposition d'utilisateurices certaines fonctionalités.

Les services hébergés par AliENS peuvent soit être issus de développements maison (par exemple : Perm'it) ou de publications open-source (par exemple : GitLab). Mais étant une association faisant la promotion du logiciel libre, les services développés par AliENS sont aussi publiés sous une license libre.

Differents type de services

Conceptuellement, AliENS héberge deux grands types de services :

les services techniques uniquement utile à AliENS : par exemple, pour faire du monitoring du système, pour gérer la comptabilité de notre association...
les services à destination du grand public.

Déclarer un service à la DSI

Conformément à notre convention d'hébergement signée avec l'ENS, AliENS n'est pas totalement maîtresse des services qu'elle héberge. Il est nécessaire d'obtenir l'aval de la DSI avant de déployer un service (article 4 de la convention).

Nous avons cependant établi lors d'une discussion avec le RSSI de l'ENS de Lyon qu'il n'était pas nécessaire de demander systématiquement une « mise à disposition de service numérique sur Internet ». Pour les services techniques, pour les services ne collectant pas de données d'utilisateurices ou pour les services hébergés une durée courte dans le temps, cela n'est pas nécessaire.

Par exemple, les services suivants ont nécessité une demande de déclaration :

GitLab
Overleaf
Perm'it
Mattermost
Wiki

Il est reconnu que les services suivants n'ont pas demandé de déclaration :

Shotguns pour divers évènements associatifs : les services ne sont opérationnels que pendant plusieurs heures.
Challenges CTF dans le cadre du club sécu : ces challenges étaient uniquement accessibles sur des ports inaccessibles hors du réseau de l'ENS. Une mise à disposition sur Internet (hors du réseau de l'ENS) n'était donc pas nécessaire.
Sites vitrines (site web du LaBi, site web d'AliENS, site web et TPs d'Azertoutes) : services presque statiques ne collectant presque aucune donnée.
Service de visualisation de données pour l'administration système (par exemple Grafana) : service à usage interne de membres administrateurices de l'association.

Pour obtenir l'aval, il faut en faire la demande via un ticket GLPI sur la plateforme assistance.ens-lyon.fr dans la catégorie DIRECTION SYSTÈMES INFORMATIONS/Demande libre.

Liste complète des services

Le dossier nixos/services/ du dépôt contient les services actuellement hébergés par AliENS. Chaque fichier ou dossier implémente un service.

Administrer les services

Ce fichier a pour but de donner des idées générales sur comment administrer les services, notamment quand ils ont des problèmes.

Systemd

La plupart des services sont implémentés par un ou plusieurs services Systemd. Par exemple,

NGINX : nginx.service
Overleaf : sandboxed-runner.service pour les compilations et podman-overleaf.service pour l'application web.

La liste des units (dont les services) peut être affichée à l'aide de la commande :

systemctl

[!note]

La liste inclut l'état des services. Elle peut être utile pour trouver rapidement les services qui sont failed.

Il est possible de voir l'état d'un service avec la commande :

systemctl status nginx.service

Les commandes systemctl start, systemctl stop et systemctl restart permettent de démarrer et arrêter un service.

Certains services sont socket-activated, c'est à dire que le service Systemd est initialement arrêté et est démarré automatiquement par Systemd dès la première connexion au socket.

Afficher les logs d'un service

Tous les logs du système sont stockés avec systemd-journald. Ils peuvent être vus avec la commande :

journalctl

La commande journalctl peut filtrer les logs pour un service avec le drapeau --unit (ou -u). Par exemple pour afficher les logs de NGINX :

journalctl --unit nginx.service

Pour n'afficher que les logs récents, il est possible d'utiliser le drapeau --since (-S) avec une durée négative. Par exemple, pour afficher les logs de NGINX depuis 1 heure :

journalctl --unit nginx.service --since -1h

Le drapeau --follow permet de suivre les logs en continu.

Machines virtuelles

Certains services tournent dans des machines virtuelles (VM). À chaque VM correspond un service Systemd nommé run-<service>-vm.service responsable du démarrage et de l'extinction douce de sa machine virtuelle.

Chaque machine virtuelle possède une IP locale du sous-réseau 10.10.10.0/24. <service>.vms.aliens-lyon.fr est un hostname alias local de l'adresse IP de la VM.

L'administration des machines virtuelles se fait en s'y connectant via SSH. La configuration SSH des utilisateurices sysadmin de « Protomolecule » spécifie une clef SSH à utiliser lors de la connexion pour des hostnames de la forme *.vms.aliens-lyon.fr. Alors, pour se connecter à une VM :

ssh aliens@<service>.vms.aliens-lyon.fr

Le username pour l'authentification dépend des VM : aliens ou debian.

Liste des services

Le Wiki d'AliENS.

Wiki d'AliENS

Mise à jour du wiki

Voici les étapes spécifiques à la mise à jour de l'instance MediaWiki d'AliENS. Dans cette section, on suppose que la mise à jour du flake du système a provoqué un changement de version de MediaWiki.

Prendre les précautions habituelles lors d'une mise à jour : effectuez une sauvegarde des données, ...
Identifier la version de MediaWiki cible de la mise à jour.

Par exemple, il est possible d'obtenir la version du package mediawiki sur search.nixos.org.
Il est nécessaire de mettre à jour les extensions MediaWiki utilisées.

Les extensions MediaWiki directement inclues dans la source de MediaWiki seront automatiquement mises à jour.

Dans les autres cas, une action manuelle est requise. Les extensions sont déclarées dans notre infrastructure via l'utilitaire mkExtension. Pour chaque extension :
1. Identifier la dernière version de l'extension compatible avec la version cible de MediaWiki et la dernière révision correspondante ;
2. Il arrive parfois que certaines extensions n'étant auparavant pas inclues dans la distribution de MediaWiki le deviennent au fil du temps. Dans ce cas, il suffit de remplacer l'appel à mkExtension dans la définition de l'extension par null. Pensez aussi à supprimer le lockfile correspondant, s'il y a un !
3. Mettre à jour les valeurs version et rev dans le code Nix ;
4. Remplacer hash par lib.fakeHash afin de laisser Nix le calculer lors du rebuild.
5. Si la définition contient composerLock, il est peut-être nécessaire de le mettre à jour. Pour faire cela, commentez la ligne en question et rebuildez. Nix génère alors un lockfile qui peut être copié pour remplacer l'ancien.
  
  [!note]
  
  S'il n'existe pas déja, définissez temporairement l'attribut vendorHash avec pour valeur lib.fakeHash. Cela permet à la dérivation d'accèder à Internet, ce qui est nécessaire pour génerer composer.lock. Supprimez-le après.
6. S'il existe, remplacer vendorHash par lib.fakeHash afin de laisser Nix le calculer lors du rebuild.
Actuellement une extension (OAuthNames) est écrite par AliENS, il sera peut-être nécessaire de la mettre à jour sur son dépôt directement !
Tester !

SSH

SSH est à la fois utilisé pour administrer le serveur, pour faire des opérations Git sur l'instance GitLab d'AliENS et dans le système de gestion de secrets où la clef SSH Ed25519 hôte de « Protomolecule » est utilisée par le système pour déchiffrer les secrets.

SSH pour administrer Protomolecule

Un serveur SSH tourne sur « Protomolecule » pour permettre à ses administrateurices de s'y connecter à distance pour l'administrer. Chacun·e peut ouvrir un shell pour son compte utilisateurice.

Il écoute sur le port 2222. Ce port n'est pas accessible depuis l'extérieur du réseau de l'ENS, ainsi il est nécessaire de s'y connecter depuis l'intérieur du reseau.

Pour cela, on utilise souvent la plateforme de ProxyJump de l'ENS, ssh.ens-lyon.fr, qui permet aux personnes ayant un compte informatique à l'ENS de Lyon d'ouvrir un shell à l'intérieur du réseau de l'ENS. Depuis ce shell, on peut SSH sur « Protomolecule ». Pour cette raison « Protomolecule » n'est administrable que par des personnes ayant un compte informatique à l'ENS.

Pour utiliser la plateforme ProxyJump de l'ENS, un peu de configuration est nécessaire pour en activer l'accès et pour installer votre clef SSH. Cette page du wiki d'AliENS donne plus d'informations sur les démarches nécessaires.

Configuration SSH d'exemple

Voici un exemple de configuration SSH à mettre dans ~/.ssh/config pour pouvoir vous connecter à « Protomolecule ». Cette configuration marchera à la fois à l'intérieur du réseau de l'ENS et à l'extérieur. Pour vous connecter, vous devrez lancer la commande ssh protomolecule.

Host protomolecule
        Hostname aliens-lyon.fr
        Port 2222
        ProxyJump <id CAS ENS>@ssh.ens-lyon.fr
        User <username Protomocule>
        # Forwarder l'agent SSH vous permet d'utiliser vos identités SSH depuis
        # Protomolecule.
        ForwardAgent yes
        # Le ProxyJump de l'ENS ferme les connexions SSH sans activité.
        # Cette option indique qu'il faut envoyer des paquets toutes les
        # 10 secondes pour garder la connexion occupée.
        ServerAliveInterval 10

[!note]

Pensez-bien à changer <username Protomolecule> et <id CAS ENS> par les informations correspondantes !

SSH dans les VM

Certains services d'AliENS sont encore hebergés dans des machines virtuelles. Leur administration se fait aussi par SSH.

SSH pour les opérations Git sur le GitLab d'AliENS

Le port 22 est réservé pour le GitLab d'AliENS : cela permet d'utiliser le GitLab sans configuration particulière, c'est à dire avec les URLs Git par défaut, et sans avoir besoin d'être à l'intérieur du réseau ENS.

Ce serveur SSH n'est pas fait pour se connecter à un vrai shell. C'est un serveur simplifié qui ne comprend que les opérations Git.

Secrets

La gestion des secrets (tokens OIDC, mots de passes, ...) se fait à l'aide de age. Ce dépôt d'infrastructure contient ainsi des fichiers .age qui sont des secrets chiffrés.

Il est important de ne pas stocker ces secrets en clair car la configuration est publique et car tout fichier d'une configuration NixOS est copié sans restriction de lecture dans le Nix store.

Ces fichiers sont chiffrés de telle sorte qu'à la fois les administrateurices système d'AliENS et « Protomolecule » lui-même soient capables de les dechiffrer. « Protomolecule » déchiffre les clefs lors de l'activation de sa configuration : ainsi, les secrets en clair seront lisibles seulement par les services qui les utilisent.

Nous utilisons agenix pour intégrer la gestion des secrets à la configuration NixOS du serveur et faire le déchiffrement pendant l'activation de la configuration.

Tous les fichiers ne sont pas destinés à être déchiffrés par « Protomolecule » : par convention, seuls les secrets dans nixos/ le sont. Les secrets en dehors du dossier sont ceux qui sont nécessaires aux administrateurices système pour récupérer un accès au serveur ou à ses données manuellement en cas de panne.

`secrets.nix`

Les clefs publiques utilisées pour chiffrer et déchiffrer les secrets sont listées dans secrets.nix. age supporte deux formats de clefs :

les clefs publiques age, qui commencent par age1 ;
les clefs publiques SSH.

« Protomolecule » utilise sa clef SSH hote, /etc/ssh/ssh_host_ed25519_key, pour déchiffrer les secrets.

Le fichier secrets.nix contient aussi la liste des fichiers de secrets avec pour chaque fichier la liste des clefs qui peuvent le déchiffrer. On retrouve les deux jeux de clefs correspondants aux deux catégories de secrets décrites plus haut.

Opérations sur les secrets et les clefs

L'outil en ligne de commande agenix est mis à disposition par le flake de ce dépôt. Ainsi, il peut être exécuté avec nix run .#agenix --.

[!important]

agenix présente quelques problèmes lorsqu'il n'est pas exécuté a la racine du dépôt. Assurez-vous de toujours être à la racine du dépôt lorsque vous l'exécutez.

Lecture d'un secret

nix run .#agenix -- --decrypt luks-backup-passphrase.age

Ajout d'un nouveau fichier de secret

Pour ajouter un nouveau secret :

ajouter son entrée dans le fichier secrets.nix
exécutez la commande :
```
 echo -n "<contenu>" | nix run .#agenix -- --edit chemin/fichier.age
```
[!tip]

L'espace avant echo permet de ne pas sauvegarder la commande dans l'historique de votre shell.

[!important]

Attention à ne pas introduire de retour à la ligne non desiré en fin de fichier ! Par exemple, le drapeau -n dans la commande echo au dessus permet de ne pas en introduire.

Changement des clefs

Après avoir ajouté ou retiré une clef dans le fichier secrets.nix, il est important de rechiffrer tous les secrets avec les nouveaux jeux de clefs. Pour cela, il faut lancer la commande :

nix run .#agenix -- --rekey

Emails d'AliENS

Il est parfois nécessaire que les services d'AliENS envoient ou reçoivent automatiquement des emails : par exemple, un service peut envoyer des notifications à ses utilisateurices par email.

Le fonctionnement des emails est tel qu'il y a conceptuellement deux parties :

l'envoi d'un email : seulement certains serveurs sont autorisés à envoyer des emails depuis un nom de domaine donné; ceci est configuré par SPF, DMARC et DKIM.

Par exemple, n'importe quel serveur ne peut pas envoyer un email depuis le nom de domaine aliens-lyon.fr. Pour envoyer un tel mail, il est nécessaire d'envoyer une requête à un serveur SMTP autorisé pour l'envoi depuis ce nom de domaine.
la réception d'emails : les emails sont reçus sur le port 25 via le protocole SMTP du serveur renseigné par l'enregistrement MX du nom de domaine dans l'adresse email destinataire du mail.

Le serveur récepteur traite ensuite le mail, en répondant éventuellement que l'adresse n'existe pas. L'email est sauvegardé dans une boîte mail et mis à disposition de clients via un protocole tel qu'IMAP.

Adresses email avec le domaine `ens-lyon.fr`

Envoi d'emails

Pour l'envoi de mail, l'IP de Protomolecule n'est pas dans l'enregistrement SPF du nom de domaine ens-lyon.fr, ce dernier étant contrôlé par l'ENS. De plus, nous ne possédons pas la clef DKIM de l'ENS. Protomolecule ne peut donc pas envoyer directement des emails pour le nom de domaine ens-lyon.fr.

Il est cependant possible de passer par le serveur SMTP de soumission de l'ENS, smtp.ens-lyon.fr au port 587. Pour certaines IPs, dont celle de Protomolecule, l'authentification n'est pas nécessaire.

Réception d'emails

Les emails en @ens-lyon.fr sont reçus par les serveurs de l'ENS de Lyon. Il n'est pas possible pour Protomolecule de se connecter à une boîte mail sans authentification.

Il n'est donc pas vraiment possible pour Protomolecule de recevoir des emails sur le domaine ens-lyon.fr.

Adresses email avec le domaine `aliens-lyon.fr`

Envoi d'emails

Étonnament, les connexions sortantes sur le port 25 par Protomolecule ne sont pas bloquées par l'ENS ou Renater. Ceci est généralement le cas pour lutter contre le spam conduisant à une mauvaise réputation des IPs.

Puisqu'AliENS contrôle les enregistrements du domaine aliens-lyon.fr, il serait possible d'envoyer des emails pour le domaine aliens-lyon.fr depuis Protomolecule.

En pratique, ce n'est pas fait comme cela pour une question de simplicité. La gestion des mails est déléguée au serveur mail.tweqx.fr selon une configuration DNS standard.

Les comptes emails disponibles sont actuellement :

test@aliens-lyon.fr
gitlab@aliens-lyon.fr
alerts@aliens-lyon.fr
noreply@aliens-lyon.fr
forum@aliens-lyon.fr
antispam@aliens-lyon.fr
auth@aliens-lyon.fr

Le serveur SMTP de soumission à utiliser est mail.tweqx.fr au port 465 (TLS). Il est nécessaire de s'authentifier avec un mot de passe propre à chaque boîte mail.

Le serveur utilisé est un serveur d'une membre d'AliENS (Lucie), il est donc très facile d'en modifier la configuration ou d'ajouter des comptes emails.

Réception d'emails

Le port 25 de Protomolecule est fermé par l'ENS. Il n'est donc pas possible de recevoir des emails sur Protomolecule.

Pour permettre à Protomolecule de recevoir des emails, la gestion des emails est donc déléguée à un autre serveur, mail.tweqx.fr. Les boîtes mails disponibles sont les mêmes que ci-dessus. L'accès à une boite mail est possible via le serveur IMAP disponible au port 993.

Serveur « Protomolecule »

AliENS possède un serveur nommé Protomolecule. Cette section contient des informations sur ce serveur.

Hardware serveur

Ce fichier documente les composants hardware du serveur. Ces informations sont disponibles, avec plus de détails, sur l'iDRAC et sur le serveur directement via des utilitaires en ligne de commande (par exemple, dmidecode).

Le modèle de Protomolecule est : Serveur rack Dell PowerEdge R540.

Carte mère :

emplacements dual-socket
16 slots pour de la RAM
6 ventillateurs (performance standard)

Processeurs (modèles de 2017) :

Intel(R) Xeon(R) Silver 4110 CPU @ 2.10GHz, 8 cœurs, 16 threads
Intel(R) Xeon(R) Silver 4110 CPU @ 2.10GHz, 8 cœurs, 16 threads

RAM (2 slots occupés) :

Kingston DDR4 KTN78Y-MIE 32 GB 2666 MHz
Kingston DDR4 KTN78Y-MIE 32 GB 2666 MHz

Disques utilisés :

WDC WDS100T1R0A SSD SATA 1 TB (numéro de série : 2140HN444613)
WDC WDS100T1R0A SSD SATA 1 TB (numéro de série : 2140HN457002)
WDC WDS100T1R0A SSD SATA 1 TB (numéro de série : 2140HN445306)

Le partitionnement des disques est documenté dans partitionnement.md.

Disques branchés mais non utilisés :

TOSHIBA MG04ACA1 HDD SATA 1 TB (numéro de série : 59URK4OVF9NF)
TOSHIBA MG04ACA1 HDD SATA 1 TB (numéro de série : 59R3K7K4F9NF)
WDC WDS100T1R0A SSD SATA 1 TB (numéro de série : 2140HN456709)

Carte réseau :

Broadcom Gigabit Ethernet BCM5720

Hébergement de Protomolecule

Protomolecule est un serveur rackable appartenant à AliENS, dont les caractéristiques techniques sont documentées ici.

Un serveur physique doit être hébergé, alimenté et raccordé à Internet pour être utilisable en pratique. Les détails de cet hébergement sont décrits ci-dessous.

Colocation

Dans le domaine de l'hébergement informatique, on appelle « colocation » le fait pour un datacenter (ici la salle SING de l'ENS) de proposer (souvent en location) de l'espace d'hébergement dans un rack. Les serveurs en colocation profitent ainsi de l'alimentation électrique, du raccordement Internet mais aussi du refroissement, de la sécurité physique du datacenter et du système incendie par exemple.

Protomolecule est hébergé·e à l'ENS de Lyon, en colocation dans la salle SING. La salle SING est située sur le campus de Monod, au sous-sol du bâtiment central au côté Nord. Elle est protégée par une porte blindée et est reliée à un système de sécurité incendie.

L'ENS de Lyon héberge Protomolecule à titre gratuit : ainsi, nous ne devons rien à l'ENS en frais d'hébergement. Mais en cas de panne matérielle, les réparations sont à la charge d'AliENS.

Il est parfois nécessaire d'intervenir physiquement sur Protomolecule pour changer ou ajouter un composant hardware par exemple. Pour cela, il faut faire la demande en avance auprès de la DSI.

Convention d'hébergement

Une convention d'hébergement est signée entre l'ENS de Lyon et AliENS. Elle place un cadre sur notre hébergement, les différentes responsabilités et droits de chacunes des parties. La convention d'hébergement courante peut-être trouvée dans le dépôt des fichiers administratifs. Elle est renouvelée tous les ans.

Dans cette convention, on trouve par exemple des informations sur la connexion réseau de Protomolecule ainsi que les ports ouverts depuis l'extérieur du réseau de l'ENS.

Elle impose aussi que les contacts de trois personnes administratrices du serveur soient communiqués à la DSI par un ticket sur le portail assistance en début d'année universitaire. Les personnes sur cette liste doivent être capable de régler un problème assez rapidement, notamment en cas de faille de sécurité.

Environnement réseau

Protomolecule est relié·e au réseau RENATER.

Adresse IP du serveur

Deux adresses IPv4 sont à la disposition de Protomolecule :

140.77.166.170 : IP principale de Protomolecule. Certains ports sont accessibles depuis Internet (en dehors du réseau de l'École).
140.77.166.171 : IP destinée à l'accès à l'interface d'administration du serveur (iDRAC). Elle n'est accessible que depuis l'intérieur du réseau de l'ENS.

L'ENS de Lyon ne supporte toujours pas l'IPv6.

Les ports ouverts sur l'IP 140.77.166.170 sont :

les ports TCP 80 et 443 (HTTP et HTTPS)
le port TCP 22 (SSH)

Sous-réseau

Protomolecule se situe dans le sous-réseau 140.77.166.0/24.

Il n'y a pas de serveur DHCP sur ce sous-réseau, il est donc nécessaire d'avoir une configuration statique : la passerelle (gateway) du sous-réseau est 140.77.166.1, et l'adresse IP est celle du serveur.

Pour que la résolution des noms de domaine fonctionne, il est nécessaire de configurer au moins un serveur DNS à utiliser (DHCP nous en aurait donné un). L'ENS de Lyon en a plusieurs, par exemple cri.ens-lyon.fr (140.77.1.32) ou dns.ens-lyon.fr (140.77.167.2).

Configuration Manuelle

Voici des commandes permettant de facilement appliquer la configuration réseau ci-dessus :

sudo ip addr add 140.77.166.170/24 dev eno1
sudo ip route add default via 140.77.166.1 dev eno1
echo "nameserver 140.77.1.32" | sudo tee -a /etc/resolv.conf

iDRAC

Notre serveur « Protomolécule » est un serveur Dell de modèle Poweredge 540 et possède un accès à iDRAC avec une licence iDRAC Basic.

Accès à l'interface d'administration

L'iDRAC est l'interface d'administration du serveur, qui permet gérer le matériel installé et changer sa configuration, d'accéder à une console KVM, etc. Cette interface est accessible à l'adresse https://aliens-poweredge-r540-idrac.ens-lyon.fr sur le réseau de l'ENS.

Pour un accès en dehors du réseau, il est par exemple possible d'utiliser le VPN de l'ENS. Une autre option consiste en l'ouverture d'un proxy SOCKS au port local 8080 par la plateforme de proxy-jump de l'ENS en utilisant la commande suivante :

ssh -D 8080 loginENS@ssh.ens-lyon.fr

Il faut ensuite configurer votre navigateur pour utiliser le proxy.

L'identifiant et le mot de passe de connexion se trouvent chiffrés dans le fichier idrac-access-credentials.age. Pour les afficher :

nix run .#agenix -- -d idrac-access-credentials.age

Partitionnement

La disposition des disques est déclarée avec disko dans le fichier nixos/hardware-specific/filesystems.nix. disko permet de formatter les disques vides à l'installation du système en une seule commande.

De la configuration disko est dérivé les partitions à monter au démarrage (options fileSystems.<mountpoint>) grâce au module NixOS disko.

Précautions à prendre pour modifier la disposition des disques

disko ne permet pas de modifier la disposition des disques. Il écrase nécessairement les données avant d'opérer et ne peut donc pas être utilisé dans ce cas.

Il faudra plutôt faire les modifications manuellement (depuis une image live) et penser à mettre à jour le fichier disko.nix pour refléter les changements. Cette modification est nécessaire à des fins de documentation, pour d'éventuelles réinstallations futures et pour le démarrage du système.

Monter les disques depuis l'image live NixOS

Il est possible de monter le système de fichier en utilisant la commande suivante dans le dépôt de l'infrastructure :

sudo nix run github:nix-community/disko -- --mode mount --root-mountpoint <point de montage> --flake .#protomolecule

Chiffrement des disques

Afin de d'empêcher qu'un tiers puisse lire les données en cas d'attaque physique du serveur, elles sont stockées chiffrées.

Ainsi, chaque disque contient une partition LUKS chiffrée pouvant être déchiffrée par :

une clef stockée dans le TPM et scellée de telle sorte qu'elle ne puisse être lue que si les mesures de la plateforme TPM soient identiques aux mesures lors du scellement de la clef ;
une passphrase de secours sauvegardée en dehors du système.

Lors du démarrage, le serveur va tenter de déchiffrer le disque en lisant la clef du TPM. Cela lui permet donc de démarrer sans intervention humaine pour lui fournir une clef.

Démarrage en utilisant la passphrase LUKS de secours

Si la clé stockée dans le TPM n'est plus accessible, il est possible de fournir la passphrase de secours afin de démarrer le serveur. Il faut se rendre sur l'iDRAC (l'interface de gestion du serveur) pour ouvrir un accès KVM sur le serveur et rentrer la passphrase.

La clef de secours de trouve (chiffrée) dans le fichier luks-backup-passphrase.age.

Mesures TPM

Une description détaillée de notre utilisation du TPM de « Protomolecule » se trouve dans la section TPM.

Puisque le partitionnement des disques est effectué dans un environement dont les mesures de platformes peuvent être différentes de celles lequel se trouve la machine en temps normal, la clé scellée doit être ajoutée au TPM après l'installation.

Secure boot

Secure Boot permet d'autoriser le démarrage d'images seulement quand elles sont signées par un jeu de clefs définies par la politique en vigueur.

Nous utilisons Secure Boot pour empêcher le démarrage sur une image non reconnue : par exemple, si quelqu'un ayant un accès physique au serveur branche une clef USB.

Ainsi, nous utilisons nos propres clefs Platform Keys (PKs) qui signent le chargeur d'amorçage systemd-boot et pour chaque génération NixOS, une image contenant :

un chemin vers le noyau à démarrer et son haché pour vérifier son authenticité,
un chemin vers l'initrd à démarrer et son haché, et
les paramètres du noyau.

Il existe plusieurs modes Secure Boot, et seuls certains modes permettent d'enregistrer (« enroll ») des nouvelles clefs. Il faut une procédure particulière pour configurer Secure Boot et enroll les clefs : il faut transitionner dans le mode Secure Boot correspondant à l'opération souhaitée.

Pour comprendre les modes Secure Boot et les transitions entre ces modes plus en détail, vous pouvez vous référer à la spécification d'UEFI.

Créer la clef de signature de l'image

Lors de l'installation, il est nécessaire de créer la clef qui signera l'image.

sudo sbctl create-keys
mv /var/lib/sbctl /mnt/persistent/var/lib/
sudo mount --bind -m -o X-fstrim.notrim /mnt/persistent/var/lib/sbctl /mnt/var/lib/sbctl

Désactiver Secure boot

Il faut désactiver Secure Boot en allant dans le BIOS en suivant la documention d'iDRAC (Figure 9, page 15).

Enfin, il est possible de redémarrer en utilisant "Reset System (warn boot)", depuis le bouton "Power".

Activer Secure boot

Dans les paramètres de l'iDRAC (« BIOS Settings » > « System Security »), activez Secure Boot. La policy doit être « Custom » pour permettre l'utilisation de clefs et certificats customisés et le mode doit être « Audit Mode » pour permettre l'installation des clefs. Pour atteindre ce mode, la figure 3 de la documentation de l'iDRAC relative à Secure Boot peut être utile. Redémarrez ensuite.

Les clefs pour Secure Boot peuvent alors être renseignées :

sudo sbctl enroll-keys --microsoft --ignore-immutable

Redémarrez le système. Normalement, le mode de Secure Boot est passé en « Deployed Mode » dans les paramètres de l'iDRAC. Activez ensuite Secure Boot et redémarrez. Vérifiez que le système démarre bien et que Secure Boot est bien activé en exécutant sudo sbctl status.

UEFI

Une entrée de démarrage indique au BIOS le point d'entrée pour un chargeur d'amorçage. L'installation de NixOS installe un chargeur d'amorçage, mais celui-ci ne crée pas d'entrée de démarrage. Pour démarrer sur la configuration installée, il est donc nécessaire d'en créer une. Pour ceci :

sudo efibootmgr --create \
  --label "NixOS" \
  --disk /dev/disk/by-id/ata-WDC_WDS100T1R0A-68A4W0_2140HN444613 \
  --part 1 \
  --loader "\EFI\systemd\systemd-bootx64.efi"

Cette commande va insérer la nouvelle entrée de démarrage en première position. Des anciennes entrées de démarrage pourraient aussi substituer d'anciennes installations. Puisque Secure Boot sera à terme activé, ces anciennes entrées menant à l'exécution de code non signé ne seront de toute façon pas utilisables. Pour voir les entrées de démarrage existantes, lancez sudo efibootmgr. Pour supprimer une entrée « BootXXX », utilisez sudo efibootmgr -b XXXX -B.

À noter que l'iDRAC crée automatiquement les entrées manquantes pour les Partitions Système EFI (ESP) qu'il trouve et pour des périphériques d'amovibles ou d'amorçage réseau ; ces entrées réapparaîtront au prochain démarrage.

TPM

Le TPM est une puce donnant accès à plusieurs mesures de configuration (PCR) dont chacune permet d'obtenir un haché d'une partie de la configuration pré-OS du serveur. Le TPM peut de plus stocker des données qui peuvent être scellées à la valeur d'une ou plusieurs PCR.

Les clefs de chiffrement des disques sont scellées par le PCR 7, relatif à la configuration Secure Boot. Ceci permet de s'assurer que le code chargé et exécuté par le serveur est signé par AliENS. Pour qu'un·e attaquant·e puisse exécuter son propre code, il serait nécessaire de désactiver Secure Boot, auquel cas la mesure PCR 7 aurait changé et le fichier scellé ne serait plus accessible.

La clef n'est pas scellée par d'autres PCR liés à la version et la configuration du firmware et des drivers (PCR 0 à 4) ainsi que le partitionnement des disques (PCR 5) car on veut pouvoir changer ces derniers sans avoir à utiliser la clef de secours.

Nous pourrions aussi sceller la clef avec les mesures liées au noyau et à l'initrd (PCR 8 et 11), toutefois ces mesures risquent d'être changées en cas de passage à une nouvelle génération NixOS. Les outils pour les gérer ne sont de plus pas encore au point. Un·e attaquant·e pourrait donc modifier la ligne de commande de démarrage de Linux pour en modifier le comportement et prendre le contrôle ; pour empêcher ceci, on désactive la possibilité de l'éditer dans le chargeur d'amorçage.

Debugging

Dans une cas où une erreur survient, l'utilitaire tpm2_rc_decode de pkgs.tpm2-tools est utile pour en obtenir une description textuelle à des fins de déboggage. Il est possible que le module TPM soit verrouillé, auquel cas il faut le réinitialiser. Pour faire, activez l'option « TPM PPI Bypass Clear » dans les paramètres de l'iDRAC. Après avoir rebooté, rendez-vous dans la console KVM où une confirmation de réinitialisation du TPM sera demandé : confirmez. Scellez la clef dans le TPM en utilisant les instructions ci-dessus, en puis désactivez de nouveau ce paramètre.

Installation initiale

Ce fichier contient des instructions d'installation de la configuration NixOS sur notre serveur, « Protomolecule ». Elles ont été écrites en parallèle de la première installation et permettraient de réinstaller notre configuration.

Voici les grandes étapes d'installation :

Se connectez sur l'iDRAC de Protomolecule
Depuis ce dernier, démarrez sur une image bootable NixOS en insérant comme CD/DVD « Virtual Media » dans la console KVM de l'iDRAC une image ISO minimale de NixOS préalablement téléchargée, cette dernière accessible depuis le menu "Boot".

Assurez-vous que Secure Boot soit désactivé dans les paramètres du BIOS.
Configurez le réseau après démarrage sur l'ISO bootable comme décrit dans la section relative à l'environement reseau de la documentation sur l'hébergement de notre serveur.
Connectez-vous par SSH au serveur.
Activez les fonctionnalités expérimentales flakes et nix-command pour les users root et nixos.
Récuperez une copie de ce dépôt sur le serveur.
Générez une clef de secours pour le chiffrement des disques :
```
tr --delete --complement '[:alnum:]' < /dev/urandom | head -c 16
```
Stockez-la chiffrée par age pour les clefs des administrateurices système dans le fichier luks-backup-passphrase.age.

Il est important que la clef de secours soit stockée chiffrée et sans risque de perte.
Formattez les disques selon le partitionnement décrit par notre configuration et montez les nouvelles partitions dans /mnt :

Attention, ceci détruit les données des disques.
```
sudo nix run github:nix-community/disko -- --mode disko --flake .#protomolecule
```

Effectuez des bind mounts pour les sous-dossiers de la partition persistante comme le ferait impermanence :

sudo mkdir -p /mnt/persistent/nix
sudo mkdir -p /mnt/persistent/var/lib/nixos
sudo mount --bind -m -o X-fstrim.notrim /mnt/persistent/nix /mnt/nix
sudo mount --bind -m -o X-fstrim.notrim /mnt/persistent/var/lib/nixos /mnt/var/lib/nixos

Créez un jeu de clefs de signature pour signer des binaires EFI.

Installez le système :

# interagir avec des flakes nécessite d'avoir `git` accessible
nix shell nixpkgs#git

sudo nixos-install --flake .#protomolecule --no-root-password

Configurez l'entrée de démarrage.
Redémarrez.
Activez Secure Boot en modifiant les paramètres du BIOS, en redémarrant et en inscrivant le jeu de clefs précédemment généré dans les variables EFI.

Une fois Secure Boot configuré, il faut sceller la clef de chiffrement dans le TPM.

Activez le TPM dans les paramètres de sécurité du BIOS, dans l'interface de l'iDRAC (« TPM Security » à mettre à « On »). Dans les paramètres avancés, sélectionnez l'algorithme SHA265.

Puis, pour scellez la clef :

sudo systemd-cryptenroll --tpm2-device=auto --tpm2-pcrs=7 /dev/disk/by-partlabel/disk-disk1-persistent1-encrypted
sudo systemd-cryptenroll --tpm2-device=auto --tpm2-pcrs=7 /dev/disk/by-partlabel/disk-disk2-persistent2-encrypted
sudo systemd-cryptenroll --tpm2-device=auto --tpm2-pcrs=7 /dev/disk/by-partlabel/disk-disk3-persistent3-encrypted

Keyboard shortcuts