Architecture Système : Cloisonnement des Rôles et Gestion des Ressources (Fedora 44 KDE)

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é 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.

1. Vision Philosophique & Modèle de Sécurité

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 :

Identité	Type de Compte	Rôle Système	Impact Sécurité

bernard	Utilisateur Standard / Sudoer	Navigation, messagerie Proton, tâches courantes.	Totalement isolé des fichiers des machines virtuelles.
tux	Compte Technique Dédié	Gestion des conteneurs, scripts d'infrastructure, Virt-Manager.	Ne possède pas les droits root globaux. Ses erreurs ne peuvent pas impacter le profil `bernard`.

2. Déploiement de l'Utilisateur Technique (Ligne de Commande)

Les commandes suivantes doivent être exécutées depuis une session active (par exemple depuis le compte bernard) dans un terminal (Konsole).

Étape 1 : Création du profil technique

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 de conteneurs :

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

Étape 2 : Sécurisation de l'accès

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

sudo passwd tux

Étape 3 : Attribution du rôle de Virtualisation (Sans accès Root)

C'est le pivot de notre architecture évolutive. Nous ajoutons l'utilisateur tux au groupe système libvirt. Cela lui donne le droit de configurer l'hyperviseur QEMU/KVM et de gérer des serveurs complets (comme YunoHost) dans Virt-Manager sans jamais avoir besoin d'utiliser sudo ou de connaître le mot de passe root de la machine :

sudo usermod -aG libvirt tux

3. Comportement du Cloisonnement et Évolutivité

Gestion Isolée de Podman (Conteneurs d'applications)

Par défaut, Fedora utilise Podman pour la gestion des conteneurs légers (Docker Hub). Podman fonctionne en mode Rootless (sans privilèges super-utilisateur). Lorsque le compte tux lancera des conteneurs, 100% de la charge utile et des images téléchargées seront stockées de manière étanche dans :

/home/tux/.local/share/containers/

Le compte bernard reste vierge de tout résidu de conteneurisation.

Gestion des Fichiers de Machines Virtuelles (QEMU/KVM)

Les images disques lourdes (fichiers .qcow2) créées par tux dans Virt-Manager devront être stockées dans un espace accessible.

/!\ Note d'Ingénierie Btrfs (Évolutivité matérielle) : Les fichiers d'images virtuelles 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.

4. Validation Métrologique

Pour vérifier que l'organisation des rôles est conforme et active sur le système, exécutez :

groups tux

Le terminal doit factuellement retourner l'appartenance aux groupes : tux : tux libvirt.