Points clés
- Ne livrez jamais de clés cloud longues aux runners : émettez les habilitations d’upload dans votre plan de contrôle ; le runner ne consomme qu’une URL à usage unique ou une session de rôle à l’échelle de quelques minutes.
- Les URL pré-signées réduisent la surface d’explosion : contraindre compartiment, préfixe, verbe HTTP, en-têtes de contrôle d’intégrité et expiration — puis journaliser l’identifiant d’octroi, pas le secret.
- Les flux façon STS ajoutent la comptabilité : assume-role avec identifiant externe, étiquettes de session pour
tenant_id/pipeline_id, et rotation obligatoire alignée sur la durée du bail runner. - L’intégrité est un manifeste structuré : consigner digests, identifiants de clés de signature et attestations runner dans une ligne unique par version d’artefact.
1. Modèle de menace : ce que veulent réellement les attaquants
Les runners compromis exfiltrent rarement via une API REST soignée — ils aspirent les variables d’environnement, détournent les secrets CI ou rejouent des jetons trouvés dans les journaux. L’objectif est que, même avec un shell, un adversaire n’obtienne au plus une fenêtre courte pour écrire sous un préfixe prédéterminé et ne puisse pas recréer d’octroi depuis l’intérieur du bail. Il faut donc séparer l’autorisation d’upload (plan de contrôle) de la mécanique d’upload (runner) et, si possible, éviter tout utilisateur IAM sur l’invité.
Pour les sorties Apple, l’intégrité ne s’arrête pas aux octets d’une archive : identité de codesign et accusés Notarization imposent déjà une frontière de secrets disciplinée sur les mêmes hôtes. La même discipline s’applique aux blobs génériques — ce qui relie cette note aux autres guides runners Mac cloud du site lorsque la chaîne mêle stockage, caches et quotas locaux.
2. URL pré-signées contre sessions STS de courte durée
Les URL pré-signées déportent la décision d’autorisation vers le plan de contrôle : le runner reçoit une URL opaque qui embarque déjà la politique (verbe, clé d’objet, éventuelle clé SSE-KMS, plafond de taille). Comme le secret ne devient pas une variable d’environnement ambiante, la surface de fuite rétrécit — à condition de rejeter les clés trop générales et de garder des TTL en minutes.
La fédération façon STS (assume-role du fournisseur cloud, OIDC depuis votre IdP CI ou courtier maison) aide pour multipart, nombreux objets par build ou nommage dynamique. Liez les sessions à runner_lease_id, plafonnez la durée au temps de job attendu plus une marge modeste, et attachez des étiquettes façon ABAC pour que les traces restent filtrables par locataire. Évitez de recycler le même identifiant externe entre environnements — ce motif fusionne discrètement les rayons d’explosion.
| Schéma | Optimal quand | Points de vigilance |
|---|---|---|
| PUT/POST pré-signés | Peu d’objets ; clés serrées ; logique runner minimale | Dérive d’horloge ; journaliser l’URL complète ; absence de contrôle d’intégrité |
| Rôle / session courte | Multipart, manifestes dynamiques, nombreuses couches cache | Politiques de confiance trop larges ; sessions qui survivent au bail runner |
| Hybride | Gros artefacts via rôle multipart ; métadonnées via petit JSON pré-signé | Champs d’audit incohérents entre les deux chemins |
Journaliser sans divulguer le pouvoir d’upload
Les journaux structurés doivent porter grant_id, compartiment, préfixe d’objet normalisé, principal émetteur et TTL restant au début d’upload — pas la chaîne de requête pré-signée. Pour STS, tracez role_arn, nom de session et jeu d’étiquettes ; faites tourner les clés de signature selon un calendrier publié pour répondre « quelle chaîne de confiance était active à 14:03 UTC ? » sans archéologie de tickets.
3. Contrôles d’intégrité runner avant « promotion »
Traitez chaque sortie de build comme non fiable jusqu’à ce qu’elle soit ancrée par des preuves collectées avant la fin de l’upload : digest cryptographique (SHA-256 ou mieux), signatures façon Sigstore si besoin, SHA Git, versions d’outil, identifiants de job OpenClaw. Les clients d’upload devraient envoyer Content-SHA256 ou équivalent lorsque le stockage le vérifie, pour que l’altération en transit échoue net plutôt que de corrompre silencieusement.
Lorsque la pression mémoire rend les compilations intermittentes, on traque parfois des fantômes réseau alors que le signal réel est la contention RAM — dimensionner les runners sur la télémétrie maintient la confiance dans ces contrôles. Pour la lecture opérationnelle des pics et du swap sur Apple Silicon, voir Apple Silicon, runners Mac cloud : pics mémoire et gouvernance du swap — compilation, Docker et Xcode : indicateurs, dégradation et paliers RAM des forfaits.
4. Pipeline d’ingestion et chaîne d’audit
Concevez trois enregistrements synchrones : (1) octroi émis — qui a approuvé le périmètre d’upload ; (2) attestation runner — manifeste de digest plus métadonnées de bail ; (3) accusé stockage — identifiant de version ou ETag du compartiment. Corrélez-les avec un artifact_id unique propagé dans les événements OpenClaw pour que webhooks consommateurs et requêtes SIEM partagent le même vocabulaire.
Les journaux immuables battent les captures d’écran : poussez du JSON structuré vers votre niveau de rétention habituel, masquez les chaînes pré-signées et ne conservez que les empreintes du matériel de signature. Si un auditeur demande « ce binaire aurait-il pu être substitué au milieu du pipeline ? », la réponse cite des horodatages alignés entre plan de contrôle, agent runner et journaux d’accès objet — pas un récit narratif. Les quotas disque et la pression inode sur les hôtes loués peuvent retarder écritures manifestes et journaux : gardez une marge SSD cohérente avec vos couches de cache — Apple Silicon — runners Mac cloud : gouvernance disque et inodes (Derived Data, couches conteneurs, journaux unifiés et caches) — alertes de quotas, nettoyage par couches et planification aux frontières du stockage des forfaits.
5. Conclusion
Le moindre privilège pour la sortie d’artefacts tient surtout à de la plomberie ennuyeuse — TTL courts, préfixes serrés, manifestes — mais c’est ce qui permet d’automatiser sans transformer chaque Mac cloud runner en identité d’administration nomade. Ancrez les contrôles dans les modèles de jobs OpenClaw tôt ; les ajouter après incident est plus lent et plus bruyant qu’un refus par défaut sur les ACL objet dès le premier jour.
Sur Mac cloud, une sortie réseau bornée s’accorde bien au débit Apple Silicon
Les runners Apple Silicon avalent vite les archives Xcode lorsque la RAM et le disque sont dimensionnés pour les pics qui se chevauchent, tandis que macOS s’intègre proprement aux flux OIDC et au trousseau — utile quand les uploads coexistent avec des identités de signature sur le même bail. Une capacité Mac mini cloud dédiée stabilise la concurrence pour que les TTL pré-signés et les sessions STS puissent être réglés serrés sans dépassements chroniques.
Si vous voulez des builds pilotés par OpenClaw sur du matériel que vous pouvez verrouiller et mesurer, kvmboot cloud Mac mini M4 constitue un point de départ pragmatique — voir les offres et tarifs et alignez les politiques de sortie d’artefacts sur du hardware réellement sous contrôle.