Pulumi - sécuriser une stack et la CI d'equipe

Pour partager un projet Pulumi local sans laisser une stack lisible par n'importe quel shell du poste, commencez par une vraie passphrase, des permissions strictes et un preview self-hosted qui lit son secret depuis un stockage adapte. Ce guide montre comment créer une stack team chiffrée, vérifier que Pulumi echoue sans passphrase, utiliser PULUMI_CONFIG_PASSPHRASE_FILE en local, durcir le backend file://~ et injecter la passphrase dans GitHub Actions via secrets. Le flux a été rejoue le 1 avril 2026 sur KVM/libvirt avec preview, up, verification virsh, puis destroy.

Ce que vous allez sécuriser

Le but n'est pas de transformer le projet en usine a gaz. Vous allez protéger les trois zones qui fuient le plus vite dans un petit workflow d'equipe :

le fichier de stack et ses secrets ;
le backend local et ses permissions ;
la CI self-hosted qui doit lire la passphrase sans la coder en dur.

Dans le lab rejoue, la stack sécurisée s'appelle team et pilote une VM pulumi-team-vm sur le réseau pulumi-team-net.

Pourquoi le workflow `dev` ne suffit plus

Dans les guides précédents, le projet était volontairement simple : stack dev, backend local, secret masque dans Pulumi et workflow self-hosted minimal. Pour apprendre, c'est très bien. Pour travailler a plusieurs, ce n'est plus suffisant.

Les risques deviennent vite concrets :

une passphrase vide laisse la stack dechiffrable sans protection réelle ;
un fichier Pulumi.<stack>.yaml trop ouvert peut être lu par un autre compte du même poste ;
un workflow CI avec une passphrase en clair dans le YAML devient une fuite de secret versionnée.

Autrement dit : la bonne question n'est plus seulement "est-ce que le preview passe ?" mais aussi "qui peut déchiffrer la stack et ou le secret circule-t-il ?".

Etape 1 - Créer une stack d'equipe chiffrée des l'initialisation

Commencez par une nouvelle stack dédiée a un usage d'equipe. Dans le lab valide, la passphrase n'est plus vide et la stack porte des noms de ressources séparés de dev.

source venv/bin/activate
export PULUMI_CONFIG_PASSPHRASE='Team-Pulumi-2026!'

pulumi stack init team
pulumi config set libvirt:uri qemu:///system --stack team
pulumi config set vmName pulumi-team-vm --stack team
pulumi config set networkName pulumi-team-net --stack team
pulumi config set vmMemoryMiB 3072 --stack team
pulumi config set vmVcpu 2 --stack team
pulumi config set adminUser devops --stack team
pulumi config set --secret adminPassword 'Team-Pulumi-2026!' --stack team
chmod 600 Pulumi.team.yaml

Verification :

pulumi config --stack team
stat -c '%a %n' Pulumi.team.yaml
sed -n '1,120p' Pulumi.team.yaml

Dans le lab rejoue, vous devez observer :

adminPassword [secret] dans la sortie de pulumi config ;
des permissions 600 sur Pulumi.team.yaml ;
un bloc encryptionsalt: et une entrée secure: dans le fichier de stack, sans secret en clair.

Etape 2 - Vérifier que Pulumi refuse la stack sans passphrase

Une stack d'equipe ne doit pas être lisible si la passphrase n'est pas fournie. Testez explicitement ce refus :

env -u PULUMI_CONFIG_PASSPHRASE \
  pulumi preview --stack team --diff --non-interactive

Dans le lab valide, Pulumi retourne :

error: getting stack configuration: get stack secrets manager: passphrase must be set with PULUMI_CONFIG_PASSPHRASE or PULUMI_CONFIG_PASSPHRASE_FILE environment variables

Ce message est utile : il prouve que la stack team n'est plus exploitable sans secret de déchiffrement.

Rejouez ensuite le preview avec la passphrase correcte :

export PULUMI_CONFIG_PASSPHRASE='Team-Pulumi-2026!'
pulumi preview --stack team --diff --non-interactive

Le preview doit alors annoncer les 7 ressources attendues et continuer a masquer userData comme secret.

Etape 3 - Éviter l'export direct de la passphrase dans le shell

Exporter la passphrase dans l'environnement fonctionne, mais ce n'est pas toujours le meilleur compromis. Pour un poste local, PULUMI_CONFIG_PASSPHRASE_FILE évite de garder la valeur dans l'historique du shell ou dans un copier-coller malheureux.

Dans le lab rejoue, ce flux fonctionne :

printf 'Team-Pulumi-2026!' > .pulumi-passphrase
chmod 600 .pulumi-passphrase

env -u PULUMI_CONFIG_PASSPHRASE \
  PULUMI_CONFIG_PASSPHRASE_FILE=$PWD/.pulumi-passphrase \
  pulumi preview --stack team --diff --non-interactive

rm -f .pulumi-passphrase

Verification : le preview passe normalement avec le fichier de passphrase, alors que le même preview sans passphrase echoue.

Important : ce fichier ne doit jamais être committe. Gardez-le hors du repo ou ajoutez-le explicitement a votre .gitignore si vous utilisez cette stratégie au quotidien.

Etape 4 - Durcir les permissions du backend local

Le backend file://~ reste pédagogique, mais il ne doit pas être lisible en groupe sur un poste partage. Dans le lab, les permissions initiales de ~/.pulumi et ~/.pulumi/stacks étaient trop ouvertes pour un usage sérieux.

Le durcissement rejoue est le suivant :

chmod 700 ~/.pulumi ~/.pulumi/stacks
chmod 600 Pulumi.dev.yaml Pulumi.team.yaml
stat -c '%a %n' ~/.pulumi ~/.pulumi/stacks Pulumi.dev.yaml Pulumi.team.yaml

Dans le lab valide, la verification retourne :

700 pour ~/.pulumi ;
700 pour ~/.pulumi/stacks ;
600 pour Pulumi.dev.yaml et Pulumi.team.yaml.

Ce n'est pas un substitut a un backend distant avec verrouillage, mais c'est un minimum sain pour un backend local sur une machine Linux.

Etape 5 - Injecter la passphrase dans GitHub Actions sans la versionner

Le workflow CI du guide précédent utilisait une passphrase vide. Pour une stack partagée, il faut sortir le secret du YAML et le fournir via secrets.

Le workflow valide dans le lab est le suivant :

---
name: pulumi-preview-secure

"on":
  pull_request:
    paths:
      - "**/*.py"
      - "Pulumi.yaml"
      - "Pulumi.team.yaml"
      - "requirements.txt"
      - ".github/workflows/pulumi-preview-secure.yml"
  workflow_dispatch:

permissions:
  contents: read

jobs:
  validate-preview:
    runs-on:
      - self-hosted
      - linux
    steps:
      - name: Checkout
        uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1  # v7.0.1

      - name: Setup Python
        uses: actions/setup-python@5fda3b95a4ea91299a34e894583c3862153e4b97  # v7.0.0
        with:
          python-version: "3.12"

      - name: Install dependencies
        run: |
          python -m venv venv
          . venv/bin/activate
          pip install -r requirements.txt

      - name: Compile Python sources
        run: |
          . venv/bin/activate
          python -m compileall .

      - name: Run unit tests
        run: |
          . venv/bin/activate
          python -m unittest discover -s tests -p 'test_*.py'

      - name: Check passphrase secret is available
        env:
          PULUMI_CONFIG_PASSPHRASE: ${{ secrets.PULUMI_CONFIG_PASSPHRASE }}
        run: |
          test -n "$PULUMI_CONFIG_PASSPHRASE"

      - name: Pulumi preview
        env:
          PULUMI_CONFIG_PASSPHRASE: ${{ secrets.PULUMI_CONFIG_PASSPHRASE }}
        run: |
          . venv/bin/activate
          pulumi login --local
          pulumi stack select team
          pulumi preview --stack team --diff --non-interactive

Verification :

actionlint .github/workflows/pulumi-preview-secure.yml
yamllint .github/workflows/pulumi-preview-secure.yml

Dans le lab rejoue, ces deux commandes passent proprement.

Trois choix sont importants ici :

le runner reste self-hosted parce qu'il doit voir qemu:///system ;
la passphrase vient de secrets.PULUMI_CONFIG_PASSPHRASE et non du repo ;
une etape intermediaire verifie que le secret est bien present avant de lancer le preview.

Etape 6 - Rejouer le cycle complet sur la stack sécurisée

Une sécurisation credible doit encore laisser le projet exploitable. Rejouez un cycle complet :

export PULUMI_CONFIG_PASSPHRASE='Team-Pulumi-2026!'

pulumi up --stack team --yes
virsh list --all | grep pulumi-team-vm
virsh domstate pulumi-team-vm
virsh domiflist pulumi-team-vm

pulumi destroy --stack team --yes

Dans le lab valide, vous obtenez :

une VM pulumi-team-vm en état running après up ;
une interface virtio reliee au réseau pulumi-team-net ;
un destroy qui supprime proprement les 7 ressources de la stack.

Cette etape compte autant que le reste. Une pile de sécurité qui empêche le travail ou casse le destroy n'est pas une bonne sécurisation.

Ce que ce guide couvre réellement

Ce guide valide trois protections utiles et concrètes :

le chiffrement de la stack avec une passphrase non vide ;
la réduction de surface locale via des permissions 600/700 ;
l'injection de la passphrase dans une CI self-hosted via un secret GitHub.

Ce guide ne valide pas encore :

un backend distant partage avec verrouillage ;
un chiffrement par KMS ;
des politiques RBAC ou SSO autour de Pulumi Cloud ;
la rotation organisationnelle des secrets a grande échelle.

Il faut rester honnête sur ce périmètre. Ici, on durcit un workflow local sérieux. On ne pretend pas encore couvrir tout le sujet plateforme.

Pieges fréquents

Symptôme	Cause probable	Solution
`incorrect passphrase`	La valeur injectee ne correspond pas a la stack	Vérifiez la passphrase active et rejouez `pulumi preview` avec la bonne valeur
`passphrase must be set with PULUMI_CONFIG_PASSPHRASE or PULUMI_CONFIG_PASSPHRASE_FILE`	Aucune passphrase n'a été fournie	Exportez `PULUMI_CONFIG_PASSPHRASE` ou pointez `PULUMI_CONFIG_PASSPHRASE_FILE`
La passphrase se retrouve dans le repo	Un fichier temporaire ou un YAML a été committe	Sortez la valeur du repo, supprimez le fichier et utilisez `secrets` ou un fichier local ignore
Le `preview` CI echoue sur `ubuntu-latest`	Le runner ne voit pas `qemu:///system`	Gardez le workflow sur un runner self-hosted Linux
Le backend local reste trop ouvert	Les permissions de `~/.pulumi` ou des fichiers de stack sont trop larges	Appliquez `chmod 700 ~/.pulumi ~/.pulumi/stacks` et `chmod 600 Pulumi.<stack>.yaml`

A retenir

Une stack d'equipe Pulumi doit exiger une passphrase non vide.
PULUMI_CONFIG_PASSPHRASE_FILE est utile pour éviter l'export direct du secret dans le shell.
Un backend local file://~ doit au minimum être limite au propriétaire sur un poste Linux.
Dans GitHub Actions, la passphrase doit venir d'un secret, jamais du YAML versionne.
Une sécurisation utile se valide encore avec preview -> up -> virsh -> destroy.

Prochaines étapes

Preview, tests et CI Revenir a la chaîne qualité Pulumi si vous voulez replacer ce guide de sécurisation dans le workflow CI d'origine.

Gerer les secrets en IaC Reprendre les principes transverses sur les secrets avant d'etendre ce durcissement a d'autres outils IaC.

State et données sensibles Approfondir les risques liés aux fichiers de state, aux artefacts et aux données sensibles autour de l'infrastructure.

Hub Pulumi Revenir a la vue d'ensemble de la section et du parcours local valide sur KVM/libvirt.