Les pipelines ne reçoivent que les secrets que vous leur accordez
Un jeton de service est créé dans votre navigateur et affiché une seule fois ; le serveur n’en garde que les clés publiques. Accordez-lui les environnements dont un pipeline a besoin, et ajoutez une liaison OIDC pour qu’il ne fonctionne que dans le bon dépôt et sur la bonne branche.
- Les jetons ne lisent que ce que vous accordez
- Liaison OIDC pour GitHub, GitLab et Bitbucket
- La production peut rester entièrement hors de la CI
Un jeton qui n’ouvre que ce que vous lui donnez
Un jeton crunu_svc_ est généré entièrement dans le navigateur de l’administrateur et affiché une seule fois. Il ne lit que les environnements que vous lui accordez : un jeton pour development ne reçoit jamais la clé de production.
- Bail, utilisations et réseauxDonnez à un jeton un bail, une limite d’utilisations de 1 à 1 000 000 et la liste des réseaux d’où il peut venir.
- Lié à votre dépôtAvec une liaison OIDC, le jeton ne fonctionne qu’accompagné du jeton de votre fournisseur de CI pour le dépôt, la branche et l’environnement de déploiement que vous avez choisis. Un jeton du fournisseur rejoué est refusé.
- Chaque utilisation est enregistréeLes connexions et les refus des jetons apparaissent dans le journal d’audit, et un jeton CI rejoué déclenche une alerte.
Trois lignes dans le pipeline
Stockez le jeton dans les variables secrètes de votre CI sous le nom CRUNU_TOKEN, installez une version épinglée de crunu et lancez l’étape via crunu run. Les variables sont déchiffrées en mémoire et rien n’est écrit sur le disque.
- Une installation épinglée et vérifiéeL’application affiche la commande d’installation avec les sommes de contrôle exactes issues du manifeste de publication signé.
- Des modules prêts à l’emploiUne GitHub Action, un modèle GitLab et un pipe Bitbucket installent une version épinglée et vérifient son SHA-256.
- Les codes de sortie sont transmis
crunu runrenvoie le code de sortie du programme lancé : un test qui échoue fait toujours échouer l’étape.
Ce que chaque système de CI peut vérifier
Dans GitHub Actions, GitLab CI et Bitbucket Pipelines, l’agent trouve seul le jeton du fournisseur de CI. Toute autre CI fonctionne avec un jeton stocké dans ses secrets.
| Système de CI | Ce que vérifie la liaison OIDC | Module |
|---|---|---|
| GitHub Actions | Dépôt, ref, environnement de déploiement | Action setup-crunu, copiée dans votre dépôt |
| GitLab CI | Chemin du projet, ref, type de ref, environnement de déploiement | Modèles .crunu et .crunu-oidc |
| Bitbucket Pipelines | Dépôt, branche, environnement de déploiement | Un pipe crunu run, image construite par vos soins |
| Tout fournisseur OIDC | Tout émetteur, clés via OIDC Discovery | Jeton et crunu run |
| Toute CI sans OIDC | Jeton seul | Jeton et crunu run |
Gardez la production hors du pipeline
La configuration recommandée ne fait jamais passer les secrets de production par la CI. L’agent tourne sur la machine de production, et le pipeline se contente de redémarrer le service.
- La machine récupère elle-même ses secretsLe serveur de production est enrôlé comme machine et reçoit son environnement directement.
- La CI ne fait que redémarrerL’étape de déploiement redémarre le service ;
crunu run --restart on-changele redémarre aussi quand les valeurs changent. - Quand la CI doit toucher à la productionUtilisez un jeton de production distinct, avec une liaison OIDC et l’approbation d’un propriétaire ; chaque remise est inscrite au journal d’audit.
Ce qu’il faut savoir avant de tout brancher
Les jetons gardent la production hors de portée. Côté CI, certaines choses restent des recettes plutôt que des boutons.
- Les modules ne sont pas sur les places de marchéCopiez la GitHub Action dans votre dépôt, et construisez et publiez vous-même l’image du pipe Bitbucket.
- Pas de synchronisation intégrée avec les plateformesAucune intégration ne pousse les valeurs vers Vercel, Cloudflare, AWS Secrets Manager ou GitHub Secrets. La méthode documentée est une recette avec crunu run.
- L’étape lit ce qu’elle reçoitTout ce qui tourne dans le job voit les variables qu’il reçoit. Accordez le moins d’environnements possible.
- Liez les jetons de productionUn jeton sans liaison OIDC fonctionne depuis n’importe quelle adresse autorisée jusqu’à sa révocation, la fin de son bail ou sa limite d’utilisations.
Réponses aux questions fréquentes
Une autre question ? Écrivez à support@crunu.com
Si un jeton fuite, peut-il lire la production ?
Non, sauf si vous lui avez accordé la production. Un jeton pour development ne reçoit jamais la clé de production. Avec une liaison OIDC, un jeton qui a fuité ne fonctionne pas du tout sans le jeton de votre fournisseur de CI pour le bon dépôt et la bonne branche.
OIDC est-il nécessaire ?
Non. Toute CI peut utiliser un jeton de service stocké dans ses secrets. OIDC ajoute une seconde vérification qui rattache le jeton à votre dépôt et à votre branche.
Où le jeton est-il stocké ?
Dans les variables secrètes de votre CI. Le serveur ne garde que les clés publiques du jeton : c’est pourquoi il n’est affiché qu’une fois et ne peut pas être récupéré.
Peut-on limiter un jeton à quelques utilisations ?
Oui. Fixez une limite d’utilisations entre 1 et 1 000 000, ainsi qu’un bail et des réseaux autorisés.
Crunu peut-il pousser des variables vers Vercel ou Cloudflare ?
Pas par une synchronisation intégrée. Vous pouvez le faire depuis une étape de pipeline avec crunu run et la commande propre à la plateforme, en utilisant un jeton lié par OIDC.
Sortez les secrets de production de votre pipeline
Créez un jeton pour un environnement staging et lancez vos tests avec crunu run.