Sécurité

Quatre règles tiennent le produit. Chacune est énoncée pour que vous puissiez la vérifier plutôt que la croire.

Rien ne se connecte vers l’intérieur

L’app ouvre une session SSH depuis votre laptop. L’agent fait des appels HTTPS sortants pour sa licence, les clés publiques et ses propres mises à jour. Ni la plateforme ni le support n’ouvrent de connexion vers votre machine.

Ce que le pare-feu laisse entrer est à votre usage : SSH sur 22, et aussi sur 443 si vous avez choisi SSH sur 443 à la sécurisation ; 80 et 443 pour le web une fois exposure.caddy installé ; et votre propre tailnet si vous installez exposure.tailscale.

Vérifiez : sudo ufw status liste exactement ces règles, chacune avec le commentaire de ce qui l’a posée : ssh, caddy, tailscale.

Deux entrées échappent à ce pare-feu, et restent fermées tant que vous ne les ouvrez pas. Docker écrit ses propres règles avant celles d’ufw : runtime.docker publie donc les ports des conteneurs sur 127.0.0.1 seulement — sur le pont par défaut et sur chaque réseau que docker network create ou Compose crée, IPv6 compris — et nomme, sur un serveur qui faisait tourner des conteneurs avant, ceux qui restent ouverts sur toutes les adresses jusqu’à leur recréation ; et -p 0.0.0.0:8080:80 les ouvre à Internet quoi qu’en dise ufw status. Tailscale SSH, une option d’exposure.tailscale, répond avant sshd : ni la fermeture de root ni fail2ban ne s’y appliquent, seule la politique d’accès de votre tailnet décide.

Aucune clé privée ne quitte votre laptop

L’app garde ses clés ed25519 dans son dossier, en 0600 : une pour cet ordinateur, et une par serveur pour lequel vous lui avez demandé d’en générer une. Une clé que vous importez y est recopiée ; un hôte déclaré dans votre ~/.ssh/config n’y met rien du tout. Seules les moitiés publiques sortent : vers l’authorized_keys du serveur, et vers la plateforme, qui les transmet aux machines de votre organisation. L’agent n’en pose une que s’il la tient déjà pour sûre, ou si elle arrive avec une autorisation signée par un appareil déjà autorisé sur ce serveur : la plateforme, qui n’a aucune clé privée, ne peut pas en fabriquer.

Vérifiez : cat ~/.ssh/authorized_keys sur le serveur ne montre que des clés publiques, et le dossier de clés de l’app sur votre laptop est le seul endroit où existe une moitié privée. Où se trouve ce dossier, et comment y pointer vos propres outils, c’est sur votre clé.

Rien de lisible n’est laissé sur le serveur

Pupitre installe un binaire compilé, des unités systemd générées et des fichiers de configuration. Il ne dépose pas de script, et ne laisse pas une copie de vos secrets dans un fichier dont il ne vous a pas parlé. Les secrets passent par l’entrée standard de la session SSH et atterrissent là où le module l’annonce, lisibles par root seul.

Vérifiez : ls /etc/pupitre/ et ses permissions.

Le support ne peut pas entrer

Le support voit ce que la plateforme sait d’un serveur : son nom, son adresse, son architecture et la version de l’agent, les services qu’il fait tourner, ses relevés de santé et l’état de ses sauvegardes. Il n’y a pas d’usurpation de votre machine, pas de shell distant, et aucune clé de support dans authorized_keys. Si un ingénieur du support a besoin de voir quelque chose sur votre serveur, c’est vous qui le collez.

La sécurisation, dans l’ordre

core.hardening ferme root en dernier, et seulement après que l’app a vérifié que votre clé ouvre dev. Si cette vérification échoue, rien n’est fermé et l’app dit quoi corriger. C’est la seule étape qui pourrait vous enfermer dehors, et elle est écrite pour ne pas le pouvoir.

Si vous préférez garder une seconde porte sur votre propre machine, l’option « Garder l’accès root » du module laisse root joignable par clé SSH. Jamais par mot de passe : l’authentification par mot de passe tombe dans les deux cas, comme tout le reste de ce que fait la sécurisation.

Sudo demande un mot de passe à dev

Tout ce qui tourne en dev — vos agents de code, le script postinstall d’un paquet, un terminal oublié — tourne sans surveillance. Pour qu’aucun d’eux ne devienne root, la sécurisation donne à dev un mot de passe sudo. L’app le tire sur votre ordinateur, n’envoie au serveur que son empreinte, et le garde dans le trousseau de l’ordinateur ; la plateforme ne voit ni l’un ni l’autre. Il s’affiche et se copie depuis la fiche du serveur, dans Réglages › Serveurs. Sous Linux sans GNOME Keyring ni KWallet, l’app le garde le temps de la session et vous demande de le noter.

Deux lignes de commande, exactement, passent root sans mot de passe : /usr/local/bin/pupitred serve et /usr/local/bin/pupitred binary install. Le binaire de l’agent appartient à root, et dev ne peut pas le remplacer. pupitred binary install pose une nouvelle version de l’agent, dont la signature est vérifiée d’abord. pupitred serve ouvre le canal de l’app, et c’est une session limitée : elle lit, agit sur les projets, les fichiers et les processus de dev, démarre et arrête les services déjà configurés, et met l’agent à jour vers une version signée au-dessus de son plancher. Elle refuse tout ce qui configure la machine — installer, désinstaller, sécuriser —, révèle un secret que root garde, importe un dump, touche aux sauvegardes au-delà de leur état, change les clés de confiance ou l’enrôlement du serveur, le redémarre, ou ramène l’agent à une version plus ancienne.

Pour ces gestes-là, l’app ouvre à la demande une seconde session, pupitred serve --privileged, avec le mot de passe sudo qu’elle garde : écrit sur la première ligne de l’entrée standard de la session SSH, jamais sur une ligne de commande. Elle la referme après une minute sans usage. Tout le reste — sudo apt install, sudo systemctl, toute autre commande de pupitred — demande le mot de passe, comme sur n’importe quel serveur bien tenu. Et l’agent, qui agit en root, ne suit plus un lien que dev a posé dans son dossier ; la sécurisation règle aussi fs.protected_hardlinks et fs.protected_symlinks à 1, dans /etc/sysctl.d/60-pupitre-links.conf, pour que le noyau refuse lui-même un lien que dev pointerait vers un fichier de root.

Un serveur sécurisé avant ce mot de passe garde l’ancienne règle, sudo sans mot de passe, tant que vous ne l’avez pas accepté : son tableau de bord le signale, et Relancer la sécurisation pose le mot de passe. Un ordinateur qui garde le mot de passe le remplace de la même façon ; un ordinateur qui ne l’a pas le saisit, et perdu partout, il se repose depuis la console de l’hébergeur ; voir le dépannage.

Vérifiez : en dev, sudo -l liste (ALL : ALL) ALL et (root) NOPASSWD: /usr/local/bin/pupitred serve, /usr/local/bin/pupitred binary install, et sudo -k; sudo true demande le mot de passe.

Une adresse publiée demande une clé

Chaque nom que exposure.cloudflare ou exposure.caddy publie passe par pupitre-gate, un portier de l’agent qui écoute sur 127.0.0.1:8098. Sans clé d’accès, il répond 401. La seule exception est un processus que vous avez déclaré public.

Les clés

• Elles sont tirées sur votre ordinateur et gardées dans son trousseau.
• Le serveur n’en garde que l’empreinte SHA-256, dans /etc/pupitre/gate/access.json, lisible par root seul.
• Créer ou révoquer une clé, ou ouvrir un projet à tous, demande votre mot de passe sudo.

Le portier

• Il tourne en root sans aucune capacité, sur un système en lecture seule.
• De /etc/pupitre, il ne voit que son propre dossier : un portier compromis ne lit ni vos secrets, ni le jeton du serveur.
• Il retire la clé avant de transmettre la requête, et remplace tout en-tête Pupitre-Identity venu de l’extérieur.

Le fonctionnement complet est dans l’accès aux adresses.

Vérifiez :

• curl -sI https://votre-projet.exemple.fr répond 401 depuis n’importe quelle machine ;
• systemctl show pupitre-gate -p CapabilityBoundingSet est vide ;
• sudo cat /etc/pupitre/gate/access.json ne montre que des empreintes.

Ce dont Pupitre ne vous protège pas

Les sauvegardes n’existent que si vous les activez : core.backup envoie des archives chiffrées dans un bucket à vous, et d’ici là rien du serveur n’est copié nulle part. Voir les sauvegardes. Pupitre n’est pas un système de détection d’intrusion, et pas un substitut à la lecture de ce que vous exécutez. Il pose ufw et fail2ban, laisse couler les mises à jour de sécurité, et se tient à l’écart.