Cette page documente la mise en place d'une structure de comptes et de privilèges asymétriques (RBAC) sur une station de travail Linux. L'objectif est de séparer l'identité du quotidien (usage bureautique/personnel) de l'identité technique dédiée au pilotage des infrastructures virtuelles (VMs KVM, conteneurs Podman/Docker).

Cette approche garantit une étanchéité totale des données et offre une structure hautement évolutive pour accueillir de futurs services (ex: serveurs YunoHost, environnements de tests) sans corrompre le profil principal de l'utilisateur.

Plutôt que d'exécuter l'ensemble des tâches d'infrastructure depuis un compte unique doté de privilèges globaux, le système applique le principe du moindre privilège à travers deux identités distinctes :

Les commandes de ce bloc doivent être exécutées depuis votre session utilisateur principale dans un terminal (Konsole).

Nous demandons à DNF5 d'installer l'interface graphique de gestion (Virt-Manager), le démon de contrôle d'arrière-plan, et les outils d'authentification client :

sudo dnf install -y virt-manager libvirt-daemon-kvm libvirt-client

Sous Fedora, les services de virtualisation ne sont pas lancés par défaut. Nous activons le démon pour qu'il s'exécute immédiatement (–now) et se relance automatiquement à chaque démarrage de la machine :

sudo systemctl enable --now libvirtd

Nous initialisons le compte tux en forçant la création de son répertoire personnel (/home/tux) pour accueillir ses futurs espaces de stockage isolés :

sudo useradd -m -c "Compte Infrastructure Tux" tux

Définissez un mot de passe robuste dédié à cette identité technique :

sudo passwd tux

Le groupe libvirt ayant été créé lors de la phase d'installation de l'hyperviseur, nous pouvons y ajouter l'utilisateur tux. Cela lui donne le droit de configurer des serveurs complets (comme YunoHost) dans Virt-Manager sans jamais avoir besoin d'utiliser sudo :

sudo usermod -aG libvirt tux

Ce bloc thématique regroupe les commandes de contrôle permettant de valider de manière indiscutable la bonne santé et l'étanchéité de la structure avant la mise en production.

Cette commande valide que l'identité technique possède bien les accès d'administration requis pour la virtualisation :

groups tux

* Résultat probant attendu : Le terminal doit factuellement retourner : tux : tux libvirt.

Cette commande interroge le gestionnaire de services pour vérifier que le moteur de virtualisation est actif en mémoire vive :

systemctl status libvirtd | grep -E "Active:|Main PID:"

* Résultat probant attendu : La ligne doit indiquer explicitement : Active: active (running).

Cette commande teste la connectivité locale du protocole client vers l'hyperviseur :

virsh --connect qemu:///system uri

* Résultat probant attendu : Le terminal doit vous renvoyer strictement la chaîne : qemu:///system.

Les images disques lourdes (fichiers .qcow2) créées par tux dans Virt-Manager génèrent des écritures aléatoires intensives. Pour éviter l'effondrement des performances du SSD dû au mécanisme Copy-on-Write natif de Btrfs, le répertoire accueillant les VMs de tux devra impérativement être créé avec l'attribut d'écriture directe No_CoW (+C) lors de la prochaine phase de refactoring des sous-volumes.