La confiance se construit par l'architecture, pas par les promesses
AtlasPVE est une couche de sécurité et d'exploitation installée à côté des serveurs Proxmox. Cette page explique ouvertement comment le produit fonctionne, où vivent les données et ce qui se passe s'il est un jour retiré ; un outil qui demande root doit d'abord rendre des comptes.
Une architecture non invasive
AtlasPVE ne patche aucun fichier du cœur de Proxmox. Chaque opération passe par les outils et API officiels de Proxmox ; l'hyperviseur n'est jamais forké et ses paquets ne sont jamais remplacés.
Les permissions ne sont pas réinventées : qui peut faire quoi est lu depuis le système de droits de Proxmox et appliqué côté serveur à chaque requête. Cacher un bouton dans un panneau ne vaut pas autorisation ; la décision se prend toujours sur le serveur.
Le composant qui tourne en root est volontairement réduit : seules l'exécution et la protection tournent en root ; l'interface et les couches de décision jamais.
Les données restent chez le client
Le produit tourne entièrement sur le serveur du client et remplit sa mission sans accès internet. Concrètement :
L'inventaire du serveur, les listes de VM et la configuration ne quittent jamais l'hôte.
Les métriques et les graphiques sont collectés localement et restent locaux.
Les journaux et la piste d'audit vivent sur l'hôte ; rien n'est envoyé vers un service externe.
Aucune télémétrie, aucune analyse d'usage.
Les mises à jour sont récupérées à la demande sous forme de paquets signés ; un paquet dont la vérification échoue n'est jamais installé.
Si internet disparaît, le panneau continue de fonctionner ; le produit ne dépend d'aucun service cloud.
Les six piliers de la confiance
Chaque affirmation de cette page correspond à quelque chose de concret dans le produit.
Désinstallation propre
La suppression tient en une seule commande et ne laisse aucun service derrière elle. Ne créer aucune dépendance est une décision de conception délibérée.
Proxmox reste intact
Si AtlasPVE est un jour retiré, Proxmox continue de tourner exactement comme avant, car aucun composant du cœur n'a jamais été modifié. Machines virtuelles, sauvegardes et snapshots restent exactement où ils sont.
Mises à jour signées
Chaque paquet de mise à jour est signé et vérifié avant installation. Si la vérification échoue, l'installation s'arrête.
Root réduit, couches séparées
Le composant root est un cœur d'exécution étroit. L'interface et la logique produit vivent dans des processus séparés sans root ; la surface d'attaque est volontairement réduite.
Divulgation responsable
Les découvertes de sécurité sont reçues à [email protected], traitées en priorité, et les correctifs sont clairement marqués dans les notes de version. Les chercheurs de bonne foi ne font jamais l'objet de poursuites.
Aucun secret dans les journaux
Les mots de passe et les jetons ne sont jamais écrits dans la piste d'audit. Les entrées portent l'action, pas les identifiants qui l'ont portée.
Questions fréquentes
- Que devient Proxmox si Atlas est retiré ?
- Rien ne change. Le cœur n'étant jamais modifié, les VM, les sauvegardes et le réseau continuent de fonctionner ; la suppression tient en une commande et ne laisse aucun service.
- Où vont les données ?
- Nulle part. Le produit fonctionne sans internet ; l'inventaire, les métriques et les journaux restent sur le serveur, aucune télémétrie n'est collectée.
- Pourquoi root est-il nécessaire ?
- Les mises à jour, le stockage et les opérations système exigent root. C'est précisément pourquoi le composant root reste étroit ; l'interface et les couches de décision ne tournent jamais en root.
- Comment les mises à jour sont-elles vérifiées ?
- Chaque paquet est signé ; la signature est vérifiée avant installation et un paquet non vérifié n'est jamais installé.
- Comment signaler une faille de sécurité ?
- À [email protected]. Les signalements sont traités en priorité ; si la découverte se confirme, la confidentialité est demandée jusqu'à la publication du correctif.
- Comment les correctifs de sécurité sont-ils annoncés ?
- Ils sont clairement marqués dans les notes de version ; l'écran de mise à jour montre quelle version porte du contenu de sécurité.
- Atlas convient-il aux environnements de production ?
- Atlas n'a pas été conçu pour remplacer Proxmox et ne le remplacera pas. Ce n'est pas une lacune mais le fondement sur lequel le produit est bâti : l'interface web, le shell et les terminaux restent exactement tels quels, les données ne quittent pas l'hôte, et retirer Atlas ne laisse pas la moindre dépendance derrière lui. C'est précisément la mesure de l'aptitude à la production, car une couche qui laisse l'infrastructure à son propriétaire est réversible par construction. Le composant qui tourne en root sur le serveur est ouvert sous AGPL ; ce qu'il fait peut être lu et audité, car la confiance se construit en étant inspectable, pas en étant promise. Dès le premier écran Atlas rend lisibles la répartition générale, la chaîne de dépendances et la direction que prend le système ; le volet exploitation attend dans la même interface, et les travaux de mise à jour, de stockage et de réseau s'effectuent avec leur impact visible à l'avance.
Fiches liées
- Exposer le panneau : ce qui change, et la voie qui change le moins Dès que le panneau est sur internet, la page de connexion devient visible pour tous et des tentatives automatiques la trouvent en quelques heures. Il y a trois voies, et celle qui protège le plus ne rend jamais le panneau visible.
- Choisir la source d’identité en créant un utilisateur : présent sur le serveur ou seulement dans le panneau Proxmox connaît deux types d’utilisateurs : des comptes système qui existent vraiment sur le serveur, et des comptes qui n’existent que dans Proxmox. Le mauvais choix empêche la connexion ou ouvre plus de portes que nécessaire.
- La console est un privilège : pourquoi elle demande sa propre autorisation Une console ressemble à un écran, mais c’est un shell. Et « peut modifier les réglages » et « peut ouvrir un shell » sont deux pouvoirs distincts ; prendre l’un pour l’autre revient à distribuer root.
- Une clé distincte pour l’automatisation au lieu d’un mot de passe partagé : les jetons et leurs limites Donner un mot de passe à un script écrit dans un fichier tout ce que cette personne possède. Un jeton est une clé distincte : révocable seule, avec une date de fin, et limitée à moins que le compte.