Secrets Bitbucket Pipelines depuis Crunu avec l’OIDC d’étape

Ce que fait Crunu dans Bitbucket Pipelines

Une étape lance votre commande via crunu run. L’agent crunu se connecte avec un jeton de service, vérifie les signatures, déchiffre les variables en mémoire et lance la commande avec elles. Rien n’est écrit sur le disque.

crunu run --env web-app/staging -- npm test

Le jeton ne reçoit que les environnements que vous accordez. Avec une liaison CI (OIDC), il ne fonctionne qu’accompagné du jeton OIDC de l’étape, pour le dépôt, la branche et l’environnement de déploiement que vous avez définis. crunu lit lui-même le jeton de l’étape dans BITBUCKET_STEP_OIDC_TOKEN.

Configuration

1. Dans Crunu, ouvrez Service tokens et choisissez New service token. Accordez les environnements dont l’étape a besoin. Le jeton n’est affiché qu’une seule fois.
2. Dans Bitbucket, ajoutez des variables de dépôt sécurisées : CRUNU_TOKEN et CRUNU_SERVER, ainsi que CRUNU_INSTALL_URL, CRUNU_INSTALL_SHA256, CRUNU_VERSION et CRUNU_BINARY_SHA256 tirées du bloc CI setup de la page du jeton. Dans le cloud, CRUNU_SERVER vaut https://app.crunu.com.
3. Facultatif : ajoutez une liaison CI (OIDC) sur la page du jeton. Choisissez le fournisseur Bitbucket, votre espace de travail et le repositoryUuid du dépôt, et si besoin branchName: main et le deploymentEnvironmentUuid de votre déploiement de production.

Exemple de pipeline

image: node:24

definitions:
  steps:
    - step: &test
        name: Tests with staging variables
        oidc:                 # only if the token has an OIDC rule
          audiences:
            - https://app.crunu.com   # your Crunu server as its own audience
        script:
          - curl -sSf "$CRUNU_INSTALL_URL" -o /tmp/crunu-install.sh
          - echo "$CRUNU_INSTALL_SHA256  /tmp/crunu-install.sh" | sha256sum -c -
          - sh /tmp/crunu-install.sh --version "$CRUNU_VERSION" --sha256 "$CRUNU_BINARY_SHA256" --user-install
          - crunu run --env web-app/staging -- npm test

pipelines:
  default:
    - step: *test

L’étape installe une version figée de crunu, vérifie le SHA-256 de l’installateur avant de le lancer, et exécute la commande dans l’image propre à l’étape, avec tous ses outils.

Pourquoi l’audience compte

Définissez comme audience l’adresse de votre serveur Crunu dans le oidc: audiences: de l’étape, comme dans l’exemple. L’audience par défaut de l’espace de travail Bitbucket fonctionne aussi, mais chaque service de l’espace de travail reçoit un jeton avec elle : une audience dédiée est donc plus sûre. Une étape peut lister jusqu’à 10 audiences. Les jetons Bitbucket ne portent pas de claim jti : le serveur Crunu traite donc une seconde utilisation du même jeton comme un rejeu et la refuse.

Le pipe crunu

Le produit comprend aussi un pipe Bitbucket qui regroupe ces étapes : il installe crunu, vérifie les deux sommes de contrôle et lance votre commande avec crunu run. Son image n’est encore publiée sur aucun registre : pour l’instant, installez donc crunu dans l’étape comme ci-dessus. Une étape qui utilise le pipe désigne son image par son adresse :

        script:
          - pipe: docker://<registry>/<name>:<tag>
            variables:
              CRUNU_TOKEN: $CRUNU_TOKEN
              CRUNU_SERVER: $CRUNU_SERVER
              CRUNU_ENV: 'web-app/staging'
              CRUNU_VERSION: $CRUNU_VERSION
              CRUNU_INSTALL_URL: $CRUNU_INSTALL_URL
              CRUNU_INSTALL_SHA256: $CRUNU_INSTALL_SHA256
              CRUNU_BINARY_SHA256: $CRUNU_BINARY_SHA256
              COMMAND: 'npm ci && npm test'

Figez l’image sur un tag de version immuable ou sur un digest. La commande s’exécute dans le conteneur du pipe, basé par défaut sur Node.js 24, et non dans l’image de l’étape. Si le jeton a une règle OIDC, ajoutez à l’étape oidc: avec l’audience de votre serveur, et OIDC: 'true' aux variables du pipe. Sans ce drapeau, le pipe ne transmet le jeton OIDC de l’étape ni à crunu ni à votre commande.

Gardez le jeton hors de portée

La commande lancée sous crunu run ne reçoit que des variables de base comme PATH et HOME, plus les variables de l’environnement, et jamais les propres identifiants de crunu. Les variables de dépôt Bitbucket restent toutefois visibles de chaque ligne de script hors du pipe et de chaque étape : la vraie protection est donc une attribution étroite. Donnez à un jeton CI l’environnement qu’il construit, et tenez production à l’écart.

Révocation

Ouvrez le jeton dans Crunu et choisissez Revoke. Sa prochaine connexion est refusée, et une étape déjà en cours se termine avec ce qu’elle a reçu. Si le jeton a pu fuiter, renouvelez aussi les clés des environnements qui lui étaient accordés et réémettez chez leurs fournisseurs les valeurs qu’ils contiennent.

Voir aussi

• La CI/CD dans Crunu
• Bitbucket Pipelines dans la documentation
• Lier un jeton par OIDC
• Jetons de service