Les secrets vont aux serveurs qui les utilisent, pas au pipeline entre les deux
L’agent crunu tourne sur vos serveurs Linux, garde les environnements déchiffrés en mémoire et lance vos programmes avec eux. La CI reçoit un jeton pour l’environnement qu’elle construit, lié à un dépôt et à une branche. Les valeurs de production n’ont pas du tout à passer par la CI.
Les questions que se posent les équipes comme la vôtre
Les questions qui reviennent quand une équipe comme la vôtre réunit ses secrets en un seul endroit. Le guide ci-dessous répond à chacune d’elles.
- Comment un serveur reçoit-il son environnement sans fichier sur le disque ?
- Comment garder les valeurs de production hors de la CI ?
- Comment lier un jeton CI à un dépôt et à une branche ?
- Qu’arrive-t-il aux services en marche si le coffre-fort est injoignable ?
- En combien de temps la révocation d’une machine prend-elle effet ?
- Peut-on ne servir production qu’à nos propres réseaux ?
- Qui peut enrôler des machines sans voir les valeurs ?
- Comment un script de déploiement sait-il pourquoi crunu a échoué ?
Les parties de Crunu qui y répondent
Chaque partie suit la même règle : le serveur garde des données chiffrées, des clés publiques et des documents signés, et ne détient jamais de clé qui ouvre vos valeurs.
Machines
Enrôlez un serveur avec un code à usage unique : l’agent crunu garde ses environnements en mémoire et lance vos programmes avec eux.
En savoir plus
CI/CD
Donnez à chaque pipeline un jeton de service limité à ses environnements, et liez-le à votre fournisseur de CI par OIDC : un jeton qui fuit ne peut pas se connecter seul.
En savoir plus
Règles réseau
Ne servez le contenu d’un environnement qu’aux réseaux IPv4 et IPv6 autorisés, avec des règles signées qu’on ne peut pas assouplir en douce.
En savoir plus
Journal d’audit
Connexions, attributions, versions, renouvellements et refus vont dans un journal chaîné par hachage, vérifiable en un clic et exportable.
En savoir plus
Contrôle d’accès
Donnez à chaque personne, machine et pipeline les seuls environnements dont ils ont besoin, avec des rôles adossés à des clés de chiffrement et pas seulement à des contrôles du serveur.
En savoir plus
Comment ça marche pour les équipes plateforme
Sur cette page
Où les secrets fuient en chemin vers un processus
C’est en faisant entrer une valeur dans un processus en marche qu’on la laisse le plus souvent s’échapper : un .env intégré à une image, une clé de production stockée dans les variables de la CI, un utilisateur de déploiement qui peut tout lire.
Le besoin : que chaque machine et chaque pipeline reçoive exactement ses environnements, que rien n’atterrisse sur le disque sans que vous l’ayez choisi, et que la révocation tienne en une seule action.
Quatre étapes d’un nouveau serveur à un service en marche
- Créez la machine. Choisissez ses environnements et leur mode de livraison : Environment key, qui donne toujours la dernière version de chaque fichier, ou Selected files, une copie scellée des seuls fichiers dont la machine a besoin. Selected files peut être révoqué sans changer la clé de l’environnement.
- Installez et enrôlez. La boîte de dialogue Enroll machine affiche une seule commande qui installe l’agent, vérifie son SHA-256 et enrôle la machine avec un code à usage unique. Le code est valable 15 minutes par défaut et 24 heures au plus, et il est lu depuis stdin ou une variable, jamais depuis un argument.
- Approuvez par l’empreinte.
crunu enrollaffiche l’empreinte de la machine. Approuvez la machine après avoir vérifié qu’elle correspond à celle de l’application. - Lancez votre service via l’agent. L’utilisateur du service doit appartenir au groupe
crunu. Avec--restart on-change, le programme redémarre avec les nouvelles valeurs dès qu’elles changent.
# /etc/systemd/system/payments-api.service
[Service]
User=payments
ExecStart=/usr/local/bin/crunu run --env payments-api/production --restart on-change -- /opt/payments-api/bin/serverCe que l’agent et les jetons font pour vous
| Besoin | Ce que fait Crunu |
|---|---|
| Aucun secret sur le disque | Le service de l’agent ne garde les environnements déchiffrés qu’en mémoire et les transmet à crunu run par un socket local ouvert au groupe crunu. Voir systemd. |
| Des fichiers là où un outil les attend | crunu pull écrit les fichiers avec les permissions 0600 en deux phases, garde la version précédente en .prev, ne suit pas les liens symboliques et refuse les fichiers de démarrage du shell, .ssh/ et les répertoires systemd. --env-out écrit un seul fichier env pour EnvironmentFile=. |
| Un agent que vous pouvez auditer | Un binaire Go statique qui n’utilise que la bibliothèque standard. Sous Linux, il est protégé des autres processus du même utilisateur, les core dumps sont désactivés, et le service tourne dans un bac à sable systemd. Les mises à jour vérifient une signature Ed25519. |
| Des serveurs qui traversent une panne | L’agent interroge le serveur chaque minute et renouvelle son bail toutes les 5 minutes. Si le serveur est injoignable, il sert le dernier état vérifié jusqu’à la fin du bail, 24 heures par défaut. |
| Une CI sans production | Les jetons de service ne reçoivent que les environnements que vous accordez, avec un bail, une limite d’utilisations et des réseaux. Une liaison CI (OIDC) lie un jeton à un dépôt, une branche et un environnement de déploiement dans GitHub Actions, GitLab CI, Bitbucket Pipelines ou chez tout émetteur OIDC. Un jeton CI rejoué est refusé. |
| Production uniquement depuis des réseaux connus | Des listes de réseaux signées et des politiques réseau d’environnement pour IPv4 et IPv6. Le durcissement s’applique aussitôt ; l’assouplissement attend 15 minutes, avec une alerte et une annulation possible, ou s’applique aussitôt avec une seconde signature. Les laissez-passer machine couvrent les changements d’adresse, 24 heures par défaut. |
| Révoquer en une seule action | Révoquer une machine efface ses environnements de la mémoire en quelques minutes tant qu’elle est en ligne, et renouvelle les clés d’environnement qu’elle détenait. Un code d’enrôlement réutilisé signale une interception possible. |
| Signaux | Des alertes pour les connexions depuis de nouveaux appareils, les codes d’enrôlement réutilisés, les machines sur de nouvelles adresses, les jetons CI rejoués, les baux expirés et les événements réseau, envoyées à un webhook signé par HMAC ou par e-mail. Slack, Microsoft Teams et PagerDuty se branchent via leurs webhooks entrants. |
Des échecs que l’on sait distinguer
Quand crunu ne peut pas transmettre les variables, son code de sortie en indique la raison : un script de déploiement peut donc réagir. Sinon, crunu run renvoie le code de sortie de votre propre programme.
| Code | Signification |
|---|---|
3 | La machine n’est pas enrôlée, ou personne n’est connecté |
4 | L’accès a été révoqué ou le bail a expiré |
5 | Pas de connexion et aucun état vérifié valide |
6 | Une vérification de signature ou de certificat a échoué |
7 | Cette adresse n’est pas autorisée par la politique réseau de l’environnement |
Là où s’arrête l’agent
- Le service tourne sous Linux avec systemd. Sous macOS,
crunufonctionne comme outil en ligne de commande, sans service en arrière-plan. Il n’existe pas de version Windows. - Ni opérateur Kubernetes, ni chart Helm, ni pilote CSI, ni fournisseur Terraform, ni SDK. Les programmes reçoivent leurs valeurs via
crunu run. - Pas de synchronisation intégrée vers Vercel, Cloudflare, AWS Secrets Manager ou GitHub Secrets. Vous pouvez pousser les valeurs depuis la CI avec
crunu runet la CLI de la plateforme. - Pas de secrets dynamiques. Crunu ne fabrique pas de mots de passe de base de données à courte durée de vie ; il faudrait pour cela une clé sur le serveur.
- Une machine est un destinataire légitime. Root sur cette machine peut lire ce qu’elle a reçu, et un processus en marche garde ses variables jusqu’à son redémarrage.
- Les restrictions réseau sont appliquées par le serveur, pas par le chiffrement. Un serveur compromis ne les respecterait pas, et toutes les machines derrière un même NAT ont la même adresse.
Chaque limite, avec ce qu’il faut faire, figure sur la page des limites.
Si vous exploitez aussi le serveur
Les équipes qui veulent le serveur en interne peuvent le faire tourner sur Docker, Cloudflare Workers, Vercel ou Google Cloud Run, et passer de l’un à l’autre avec une seule archive qui ne contient aucune valeur en clair. Une commande doctor vérifie un déploiement, et un point d’accès d’état expose les métriques au format Prometheus. Le serveur n’est pas proposé en téléchargement public. Écrivez à support@crunu.com. La page d’auto-hébergement compare les plateformes.
Documentation et intégrations associées
- Installer l’agent sur un serveur
- Machines et baux
- crunu run
- crunu pull
- Enrôler une machine et lancer le service
- Variables d’environnement et codes de sortie
- Lier un jeton de service à la CI par OIDC
- Réserver production au réseau du bureau
- Auto-hébergement : présentation et plateformes
- systemd
- Docker
- GitHub Actions
- GitLab CI
- Bitbucket Pipelines
Questions et réponses
Votre question n’est pas traitée ici ? Écrivez à support@crunu.com : une personne vous répondra.
Qu’arrive-t-il aux services en marche si Crunu est injoignable ?
Ils continuent de fonctionner. L’agent sert le dernier état vérifié jusqu’à la fin de son bail, 24 heures par défaut. S’il n’y a pas d’état valide, crunu run se termine avec le code 5.
En combien de temps la révocation d’une machine prend-elle effet ?
En quelques minutes tant que la machine est en ligne : l’agent interroge le serveur chaque minute et efface ses environnements dès qu’il est révoqué. Une machine qui reste hors ligne perd l’accès à la fin de son bail.
La CI peut-elle déployer en production sans voir les secrets de production ?
Oui, et c’est la configuration que recommande Crunu. Le serveur de production fait tourner l’agent et récupère lui-même son environnement ; le pipeline livre le code et redémarre le service.
crunu fonctionne-t-il dans des conteneurs ?
Le script d’installation a un mode sans root prévu pour la CI et les conteneurs, testé dans les images node:24, Ubuntu 24.04 et Alpine 3.22. Avec un jeton de service, crunu se connecte et déchiffre à l’intérieur de son propre processus, sans fichiers d’état.
Quelqu’un peut-il enrôler des machines sans voir aucune valeur ?
Oui. Le rôle Operator sur un environnement n’a pas de clé : il ajoute des machines et demande l’accès pour elles, et un propriétaire ou un administrateur approuve.
Prenez-vous en charge Kubernetes ?
Non. Il n’y a ni opérateur, ni chart Helm, ni pilote CSI.