Si vous exécutez des agents macOS Jenkins ou Buildkite sur des hôtes Mac distant dédiés répartis entre Singapour, le Japon, la Corée, Hong Kong, la côte est et la côte ouest des États-Unis, et que vous faites déjà tourner des runners self-hosted GitHub Actions ou GitLab, la douleur budget et audit n’est souvent pas le vCPU — c’est la surface d’impact des identifiants imposée par un second contrôleur : qui détient un PAT 90 jours, quel contexte utilisateur possède la trousseau match et la session ASC, et si les hôtes burst sont reconstruits avec des secrets figés dans l’image. Cet article propose trois registres — topologie des identifiants, règles de mutex, comptabilité des baux — et complète le runbook de bail échelonné Jenkins/Buildkite ainsi que la checklist labels et secrets des runners : celles-ci couvrent les files ; celle-ci couvre identités, OIDC et révocations.
~/.ssh pour Jenkins, buildkite-agent et actions-runner sous la même session transforme la CI sans présence en builds verts fragiles dès que git credential-osxkeychain invite une saisie.La valeur des six régions, c’est la colocation prévisible et l’IO dédiée ; une topologie d’identifiants floue ne fait qu’amplifier la confusion. Avec aussi la CI hybride Xcode Cloud, il faut préciser quelle identité peut toucher l’ASC contre les registres internes — sinon la matrice hybride devient incident hybride.
Introduisez un RACI identifiants : plateforme détient utilisateurs machine et liaisons OIDC, dépôts détiennent périmètres de workflow, sécurité détient exercices de révocation. Tout trou explose à l’entrée en prod du second contrôleur.
| Critère | Favoriser PAT longue durée / clés de déploiement | Favoriser OIDC / jetons courts |
|---|---|---|
| Bail | Uniquement sur hôtes baseline mensuels ou plus avec injection de secrets hors image | Éligible pour burst quotidien/hebdo si les conditions de confiance sont strictes |
| Grain d’audit | Exige des journaux supplémentaires « qui a placé le PAT sur quel hôte » ; la rotation suit souvent les trimestres financiers | Le cloud peut lier dépôt, environnement, pool — attribution par job plus simple |
| Écosystème plugins Jenkins | Beaucoup de plugins supposent des fichiers d’identifiants statiques | Nécessite des refactors explicites de pipeline ; coût initial plus élevé |
| Buildkite | Les hooks peuvent exporter des secrets silencieusement | Les hooks ne font qu’assembler ; secrets issus de jetons courts échangés via OIDC |
| Runner GHA/GitLab | Les runners self-hosted gardent souvent de longs fichiers .credentials |
L’OIDC vers le STS cloud est mainstream — alignez-vous d’abord là-dessus |
Ligne rouge : ne créez pas de PAT longue durée ni de clés de déploiement racine à l’échelle de l’organisation sur des hôtes burst quotidiens. Si le métier insiste, liez la durée des secrets aux plafonds de bail dans le même ticket d’approbation.
jenkins, buildkite, runner ; interdire les logins interactifs partagés pour la CI.ROUTING.md et les commentaires de pipeline.# Example mutex (replace flock backend with your coordination service)
exec 9>/var/lock/match-decrypt.lock
flock -n 9 || { echo "match decrypt busy"; exit 42; }
# Example split users (LaunchDaemon sketch—do not copy paths blindly)
# UserName=buildkite vs UserName=runner — each HOME keeps its own git credential helper config
.env universel gelé dans l’image est pire en 2026 que de sauter le second contrôleurLa trousseau manuelle n’est pas auditable : qui a déverrouillé en dernier, si une session interactive est restée ouverte — ce n’est pas une preuve SOC2. Un .env universel élargit la surface d’un seul dépôt à quiconque peut lancer un conteneur — contraire au moindre privilège OIDC par job.
Lorsque Jenkins/Buildkite et les runners doivent coexister sur un Apple Silicon dédié avec egress régional stable et baux baseline versus burst séparables, le Mac mini cloud MACCOME est souvent le meilleur ancrage physique : nœuds à Singapour, au Japon, en Corée, à Hong Kong, US East et US West avec baux journaliers/hebdomadaires/mensuels/trimestriels flexibles. Consignez qui peut résider sur quel hôte combien de temps avant de courir après le débit de compilation — ne figez jamais un PAT 90 jours sur un hôte quotidien tout en lançant cinq simulateurs et trois envois notaire.
Livrez trois tableaux : utilisateur machine ↔ carte HOME, ressources mutex ↔ noms de verrous, confiance OIDC ↔ périmètres STS. Une nouvelle recrue doit pouvoir dire quelle identité un job utilise, quelle classe de jeton révoquer en panne, et pourquoi aucun PAT 90 jours ne vit sur les hôtes burst.
Avec la checklist secrets des runners, fusionnez « OIDC côté GitHub » et « partitions trousseau macOS » dans le même ticket — sinon les politiques semblent parfaites dans le cloud pendant que les partitions sont vides sur le métal.
FAQ
Jenkins, Buildkite et un runner GitHub Actions peuvent-ils coexister sur un même hôte ?
Oui avec utilisateurs séparés, partitions de trousseau et étapes exclusives sérialisées ; évitez un PAT longue durée unique sur toutes les piles. Détails des files dans le runbook de bail échelonné. Paliers publics : tarifs de location.
Pourquoi ancrer les secrets longue durée sur les hôtes baseline mensuels ?
Les hôtes quotidiens changent souvent ; les secrets statiques fuient vers images ou sauvegardes. Les hôtes baseline ancrent l’identité d’audit. Contexte opérationnel aussi via commander Mac mini cloud.