Isolation de la passerelle OpenClaw sur Mac mini cloud partagé loué

La passerelle OpenClaw sur un Mac mini cloud loué rapproche les services macOS authentiques sans achat immédiat d’Apple Silicon—un ordre de grandeur utile est d’environ 16,9 USD par jour. Le piège est de traiter la machine comme un VPS Linux jetable : plusieurs opérateurs, comptes d’automatisation et « images dorées » du fournisseur se superposent discrètement. Ce guide insiste sur l’hygiène multi-locataire : isoler ~/.openclaw ou OPENCLAW_HOME, attribuer un Label LaunchAgent unique par passerelle, survivre aux clones UID des gabarits, prévenir les collisions de ports et sockets UNIX, et répartir les secrets entre variables d’environnement et le trousseau. Pour l’onboarding initial, lisez aussi onboarding passerelle et TCC ; si les jobs dérivent après upgrade, alignez-vous sur redémarrage et récupération LaunchAgent.

Carte des risques pour passerelles partagées

Les hôtes partagés amplifient trois modes : fuite d’état (les sessions écrasent la config des autres), confusion du planificateur (labels launchd dupliqués) et dérive d’identité (images clonées réutilisent le même UID ; les chemins plist semblent valides mais visent la mauvaise personne). Le tableau ci-dessous associe risque et atténuation—appliquez-les avant toute exécution de openclaw gateway install.

Risque	Manifestation	Atténuation
Racine de configuration par défaut partagée	Verrous SQLite, identifiants mélangés, plantages obscurs	Forcer OPENCLAW_HOME par personne sous ~/Users/<short>
Labels LaunchAgent en double	Un seul job tourne réellement	Préfixe locataire, ex. com.acme.openclaw.gateway.alice
Clone UID dans l’image	plists pointent encore vers /Users/build	Bootout des jobs obsolètes ; réinstall après premier login réel
Chevauchement TCP/socket UNIX	EADDRINUSE, healthchecks erratiques, boucles de retry	Allouer des blocs du type 18789–18809 par siège
Fichiers de clés lisibles par tous	Un cat fuit entre sessions SSH	Jetons longue durée dans le trousseau ; stubs d’env en chmod 600

Prévoyez 30 à 45 minutes pour la première validation de bout en bout : passerelle up, agent connecté, invites TCC passées, auto-guérison après reboot. Sauter la répétition transforme « ça marchait sur mon portable » en incident nocturne dès qu’un second prestataire rejoint la même mini.

OPENCLAW_HOME par opérateur

Sur un Mac perso, ~/.openclaw suffit ; sur une location partagée c’est un piège à éviter. Créez un dossier par opérateur (mkdir -p ~/.openclaw-alice) et exportez OPENCLAW_HOME dans son profil shell avant install ou doctor. Documentez le chemin dans le wiki interne pour éviter que l’astérisque du tilde ne soit interprété uniformément à tort.

Pourquoi éviter l’ACL de groupe sur un arbre unique ? La passerelle mélange métadonnées d’appareils authentifiés, caches locaux et IPC supposant un seul writer. Les groupes POSIX ne remplacent pas la tenancy logique ; ils retardent seulement le conflit quand deux passerelles tentent de binder le même socket UNIX sous $OPENCLAW_HOME/tmp. Pour les sauvegardes, tarball par préfixe vers l’objet stocké, jamais un rsync fusionné.

Les comptes d’automatisation sont aussi des locataires. Un utilisateur CI pour les healthchecks reçoit OPENCLAW_HOME=/var/lib/openclaw-ci avec ownership correcte plutôt que de parasiter l’arbre humain. Les audits « quel arbre détenait cette clé API ? » deviennent alors répondables.

Ne mélangez pas comptes démo et production dans le même OPENCLAW_HOME. Des jetons éphémères de campagne laissés dans une SQLite partagée exposent l’historique au locataire suivant ; la checklist impose suppression sécurisée avant restitution.

Labels et chemins LaunchAgent

macOS identifie les LaunchAgents par Label. Les collisions mènent à un comportement indéfini—souvent la seconde plist reste avec un avertissement Console ignoré. Standardisez le DNS inverse incluant équipe et siège : com.yourorg.openclaw.gateway.designer1. Harmonisez les noms de fichier avec les labels pour accélérer le grep incident.

Les ProgramArguments doivent référencer en absolu la toolchain réelle (npm global, brew, tarball épinglé). Après petites mises à jour macOS du fournisseur, revérifiez les chemins binaires ; Homebrew réorganise Cellar et les symlinks en silence. Procédure sûre : launchctl bootout de l’ancien job, remplacement du fichier, bootstrap—le hot-swap sans bootout laisse des états zombies qui masquent l’erreur réelle.

Redirigez StandardOutPath et StandardErrorPath vers des journaux par OPENCLAW_HOME. Un /tmp/openclaw.log commun provoque des guerres chmod et des fuites de jetons si le debug est activé. La rotation par locataire aide à prouver qui a déclenché un redémarrage lors d’un contrôle conformité.

Deux passerelles (canary + stable) pour un même login exigent deux labels et deux OPENCLAW_HOME, plus une matrice runbook : label, bloc de ports, chemin de log, propriétaire.

Clones UID et réinitialisations d’image

Les fournisseurs livrent souvent des images figées où l’utilisateur modèle garde /Users/build ou /Users/macuser avec UID 501. Lors du clonage pour un nouveau locataire, sans nettoyer ~/Library/LaunchAgents et le domaine bootstrap de cet UID, launchd peut recharger d’anciens jobs modèle. Connectez-vous toujours en tant qu’utilisateur de production, exécutez id -u et vérifiez avec launchctl print gui/$(id -u) que seuls vos labels apparaissent.

Si seul le hostname change sans assainissement des homes, ne réutilisez pas les noms courts de démo. Un com.vendor.openclaw survivant dans un snapshot peut revenir après reboot. La checklist numérotée rend le bootout obligatoire, pas facultatif.

Rarement, une migration ratée donne le même UID à deux comptes humains—les permissions ne réparent pas le graphe launchd ; OpenClaw lit de mauvaises entrées de trousseau. Escalade fournisseur ; au quotidien, choisissez un hébergeur garantissant des comptes locaux uniques par abonnement.

Les équipes globales doivent tenir compte des fuseaux et de l’heure d’été : les fenêtres cron/LaunchAgent glissent ; figez les créneaux de maintenance en UTC et documentez-les dans StartCalendarInterval pour éviter les malentendus de garde.

Collisions de ports et sockets

Les écouteurs TCP et les sockets UNIX constituent la surface de collision la plus bruyante. Attribuez des plages documentées—exemple : Alice 18789–18799, Bob 18800–18810—et versionnez la carte dans le dépôt infra. Surchargez les valeurs par défaut d’OpenClaw ou du proxy adjacent pour qu’une course au redémarrage ne vole pas le port voisin.

Les sockets UNIX doivent vivre sous OPENCLAW_HOME/run ou tmp, pas en /tmp/openclaw.sock global. Après arrêt brutal, des fichiers socket peuvent persister ; les scripts de démarrage doivent unlink les chemins connus ou échouer clairement plutôt que semi-binder. Si nginx ou Caddy cohabitent sur la même mini, séparez les configs par locataire sous /opt/tenants/<name> pour éviter des include accidentels.

Les healthchecks externes doivent cibler explicitement le port locataire. L’hypothèse générique « localhost:gateway » échoue dès qu’il existe deux passerelles. Notez l’URL de santé sur la même ligne que OPENCLAW_HOME pour empêcher les mauvaises copies .env depuis Slack.

Avec Tailscale ou WireGuard, enregistrez IP virtuelle et blocs de ports dans le DNS interne afin que deux personnes ne mappent pas le même loopback vers des tunnels différents et ne génèrent pas de faux positifs.

Environnement contre trousseau

Les variables d’environnement se chargent tôt, conviennent au SSH non interactif et rappellent les pratiques twelve-factor—mais sur Mac partagé, les dotfiles deviennent world-readable si l’on oublie chmod 600. Plusieurs admins lançant ps eww en parallèle voient brièvement l’environnement au démarrage.

Le trousseau macOS attache les secrets à l’utilisateur connecté et limite la lecture inter-locataire lorsque les droits UNIX sont sains. Les passerelles lancées par LaunchAgent héritent du trousseau déverrouillé de la session GUI ; les configurations headless nécessitent une procédure de premier déverrouillage documentée à côté des guides TCC. Les jetons CI éphémères arrivent depuis un gestionnaire de secrets vers l’environnement avec rotation agressive—jamais dans une .zshrc partagée.

Politique pragmatique : clés API personnelles longue durée → entrées trousseau par opérateur ; clés d’automatisation courtes → dictionnaire EnvironmentVariables dans la plist d’automation avec chmod 0400 sur la plist ; maîtres break-glass → hors ligne, jamais sur le disque loué. Revoyez chaque trimestre car la surface secrète d’OpenClaw évolue.

Si l’infra vit dans Git, chiffrez (sops, etc.) avant push ; .env.example ne contient que des placeholders, même pour des « clés de test ».

Checklist numérotée avant offboarding

Avant restitution ou ré-imaging de la mini cloud, exécutez la séquence sous les yeux d’un second ingénieur—pas de passage solo silencieux.

1. Exporter les preuves : tarball OPENCLAW_HOME, copies plist, journaux 24h vers stockage chiffré ; noter versions CLI et passerelle.
2. Révoquer les identifiants : rotation des clés API OpenClaw et refresh OAuth ; invalider les anciens identifiants dans l’IdP.
3. Bootout LaunchAgents : pour chaque label locataire, launchctl bootout gui/$UID ~/Library/LaunchAgents/<fichier>.plist puis contrôle avec launchctl print.
4. Supprimer les fichiers plist : retirer les entrées OpenClaw de ~/Library/LaunchAgents pour empêcher la résurrection par clonage.
5. Purger les racines de config : shred des OPENCLAW_HOME par locataire ou effacement sécurisé du volume selon la politique.
6. Nettoyer le trousseau : supprimer les éléments OpenClaw ; vérifier qu’aucune recherche ne renvoie de résidu.
7. Libérer les ports : confirmer qu’aucun écouteur n’occupe les blocs alloués ; transmettre la trace au locataire suivant.
8. Retirer les fragments d’environnement partagés : profils shell, injections /etc/paths.d, crontabs CI pointant vers d’anciens homes.
9. Sanity TCC : consigner les approbations vie privée restantes ; réinitialiser si le prochain locataire ne doit pas hériter caméra/micro/automation.
10. Ticket fournisseur : joindre la somme de contrôle du tarball de preuve et la confirmation qu’aucun label LaunchAgent de votre org ne subsiste.

Si une étape échoue, suspendez la passation. Une effacement partiel est pire qu’un retour tardif—il léguerait un état fantôme, exactement ce que l’isolation doit éliminer.

FAQ

Deux ingénieurs peuvent-ils partager ~/.openclaw en toute sécurité sur le même Mac mini cloud ?

Non. Le répertoire mélange bases runtime, confiance appareil et caches de session ; des passerelles concurrentes se disputent le même socket et les approbations TCC. Donnez à chacun OPENCLAW_HOME dans son dossier utilisateur.

Pourquoi les images clonées du fournisseur cassent-elles les LaunchAgents après offboarding ?

Les images dorées conservent souvent le même UID numérique et d’anciens chemins plist ; launchd peut ressusciter le label d’un autre locataire ou pointer Program vers un utilisateur supprimé. Toujours bootout les anciens jobs, nettoyer LaunchAgents et réinstaller depuis le compte actif.

Les clés API OpenClaw doivent-elles vivre dans des fichiers d’environnement ou le trousseau macOS ?

Sur hôte partagé : jetons personnels longue durée dans le trousseau ; injections façon CI rotatives à l’heure dans des fichiers d’environnement clairs. Ne commitez ni l’un ni l’autre sur le disque partagé sans droits par locataire.

Pour des passerelles OpenClaw qui exigent un comportement macOS authentique, le Mac mini reste le point d’ancrage pratique. MacHTML loue des Mac mini cloud avec SSH et VNC afin que les équipes répètent l’isolation et l’hygiène LaunchAgent sans CapEx matériel—montez en charge quand macOS est nécessaire, éteignez quand la passerelle migre vers du métal dédié.