Confiance et provenance Helm : signer vos charts pour sécuriser la supply chain

La provenance Helm garantit que le chart installé vient bien de l'auteur attendu et n'a pas été modifié. Un fichier .prov contient une signature cryptographique du chart : si l'archive est altérée, la vérification échoue. C'est une couche essentielle contre les attaques de chaîne d'approvisionnement.

Prérequis

• Helm v4.3 installé, la version sur laquelle ce guide est mesuré
• GPG installé (gpg --version)
• Un chart prêt à signer
• Module 10, OCI registries (recommandé)

Ce que vous allez apprendre

• Pourquoi signer ses charts
• Créer une clé GPG
• Signer un chart
• Vérifier un chart avant installation
• Distribuer la clé publique
• Limites et alternatives

---

Pourquoi signer ses charts

Un chart Helm est une archive .tgz téléchargée depuis un dépôt distant, puis appliquée telle quelle sur votre cluster. Rien dans le protocole ne prouve qui l'a produite : le TLS protège le transport, pas le contenu, et un index.yaml compromis suffit à rediriger vers une archive modifiée. La signature déplace la confiance du serveur vers l'auteur, par une preuve vérifiable hors ligne.

Le problème : la supply chain attack

L'enchaînement type se déroule sans qu'aucune étape ne paraisse anormale côté utilisateur :

1. Vous utilisez un chart public largement diffusé
2. Un attaquant compromet le dépôt, ou s'interpose sur le réseau
3. Vous téléchargez un chart modifié portant une porte dérobée
4. Celle-ci s'exécute dans votre cluster, avec les droits du compte qui a lancé la commande

Le risque n'a rien de théorique. Plusieurs attaques de chaîne d'approvisionnement ont visé des dépôts de paquets publics, npm, PyPI et crates.io notamment, en publiant des versions altérées sous des noms légitimes. Les charts Helm ne sont pas immunisés : ils se distribuent par les mêmes mécanismes, un serveur HTTP et un index, avec les mêmes points de confiance.

La signature cryptographique est la seule garantie que le contenu n'a pas été altéré entre l'auteur et vous. Ni le HTTPS ni la réputation du dépôt ne l'apportent : le premier protège le transport, la seconde ne protège rien du tout si le compte de publication est compromis.

Ce que garantit la signature Helm

La signature répond à une question précise : « ce fichier est-il exactement celui qu'a produit le détenteur de cette clé ». Les trois propriétés ci-dessous en découlent, et elles ne valent que si vous avez obtenu la clé publique par un canal de confiance, indépendant du dépôt de charts.

Aspect	Garantie
Intégrité	Le chart n'a pas été modifié depuis la signature
Authenticité	Le chart a été signé par le détenteur de la clé privée
Non-répudiation	L'auteur ne peut pas nier avoir signé

Glissez pour voir

Ce que la signature ne garantit pas

Une signature valide n'est pas un certificat de bonne conduite : elle atteste l'origine, pas la qualité ni les intentions. Confondre les deux conduit à installer sans relecture un chart signé qui monte /var/run/docker.sock ou réclame le rôle cluster-admin. La signature complète l'analyse du contenu, elle ne la remplace pas.

Aspect	Limitation
Qualité du code	Un chart signé peut contenir des bugs ou vulnérabilités
Intention malveillante	L'auteur légitime peut publier un chart malveillant
Sécurité de la clé	Si la clé privée est compromise, les signatures sont inutiles

Glissez pour voir

---

Créer une clé GPG

La signature Helm repose sur GPG : vous générez une paire de clés, gardez la partie privée pour signer, et diffusez la partie publique pour que d'autres vérifient. Fixez une date d'expiration dès la création : c'est le seul mécanisme qui limite les dégâts si la clé fuit à votre insu, et elle reste prolongeable. La passphrase protège le fichier de clé privée mais gêne l'automatisation, d'où la clé dédiée à l'intégration continue.

1. Générer une paire de clés

   gpg --full-generate-key

   Quatre réponses sont attendues, et chacune engage la suite :

   • Type : RSA and RSA, la première option
   • Taille : 4096 bits, le coût de calcul étant négligeable ici
   • Expiration : 2 ans, toujours préférable à « jamais »
   • Identité : celle qui figurera dans la sortie de helm verify

2. Lister les clés disponibles

   gpg --list-secret-keys --keyid-format LONG

   Résultat :

   sec   rsa4096/ABCD1234EFGH5678 2026-02-01 [SC] [expires: 2028-02-01]
         Key fingerprint = 1234 5678 ABCD EFGH ...
   uid                 [ultimate] Helm Charts <helm@example.com>

   Notez l'ID de la clé : ABCD1234EFGH5678

3. Exporter la clé publique

   gpg --armor --export ABCD1234EFGH5678 > helm-charts.pub.asc

   Ce fichier sera distribué aux utilisateurs pour vérifier vos charts.

Créez une clé séparée pour la signature automatique en intégration continue, distincte de votre clé personnelle. La raison est pratique autant que théorique : une clé de chaîne d'intégration se révoque sans casser vos autres signatures, et son usage est traçable indépendamment du vôtre. La clé privée vit alors dans un gestionnaire de secrets, jamais dans le dépôt.

Et ne partagez jamais une clé privée, pas même avec une autre équipe : on duplique un risque, on ne duplique pas une confiance. Deux équipes qui signent avec la même clé rendent toute enquête impossible le jour où une signature pose question.

---

Signer un chart

La signature n'est pas une étape séparée : elle se fait pendant le packaging, parce qu'elle porte sur l'archive .tgz finale. Signer après coup supposerait de recréer exactement la même archive, ce qui n'est pas garanti. Concrètement, helm package --sign remplace votre helm package habituel et produit un fichier de plus.

Signature manuelle

--key accepte l'identité de la clé (son nom ou son adresse), --keyring désigne le fichier de trousseau contenant la clé privée.

# Packager ET signer en une commande
helm package ./my-chart --sign --key "Helm Charts" --keyring ~/.gnupg/secring.gpg

Helm lit l'ancien format de trousseau GPG, celui que les versions récentes de l'outil n'écrivent plus. C'est la cause la plus fréquente d'un helm package --sign qui ne trouve pas la clé alors que gpg --list-keys l'affiche. L'export préalable règle le cas :

gpg --export-secret-keys > ~/.gnupg/secring.gpg

Résultat

La signature ne modifie pas l'archive : elle produit un second fichier, à côté. C'est décisif pour la distribution, puisque les deux doivent voyager ensemble. Une archive publiée seule est invérifiable, et helm verify échoue alors sur l'absence du fichier de provenance.

Deux fichiers sont créés :

my-chart-1.2.3.tgz       # Le chart packagé
my-chart-1.2.3.tgz.prov  # Le fichier de provenance (signature)

Contenu du fichier .prov

Le .prov est un message signé en clair : vous pouvez l'ouvrir dans un éditeur, il reste lisible. C'est ce qui permet de comparer à l'œil les métadonnées annoncées avec celles du chart, avant même de lancer la vérification.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

apiVersion: v2
appVersion: "2.0.0"
description: My awesome chart
name: my-chart
version: 1.2.3

...
files:
  my-chart-1.2.3.tgz: sha256:abc123def456...
-----BEGIN PGP SIGNATURE-----
...
-----END PGP SIGNATURE-----

Le .prov contient :

• Les métadonnées du chart
• Le hash SHA256 du tarball
• La signature GPG de l'ensemble

---

Vérifier un chart avant installation

La vérification est à la charge du consommateur du chart : Helm ne la déclenche pas tout seul. Sans helm verify explicite, ou sans l'option --verify sur helm install, un chart signé s'installe exactement comme un chart non signé, y compris si le .prov est absent. Vérifier suppose deux choses réunies : le .prov téléchargé à côté du .tgz, et la clé publique déjà dans votre trousseau.

Vérification avec clé importée

Ces trois étapes sont à enchaîner dans l'ordre, la vérification devant précéder l'installation.

1. Importer la clé publique de l'auteur

   gpg --import helm-charts.pub.asc

2. Vérifier le chart

   helm verify my-chart-1.2.3.tgz

   Succès :

   Signed by: Helm Charts <helm@example.com>
   Using Key With Fingerprint: 1234 5678 ABCD EFGH ...
   Chart Hash Verified: sha256:abc123def456...

3. Installer si vérifié

   helm install my-release my-chart-1.2.3.tgz -n prod

Que faire si la vérification échoue ?

Un échec ne veut pas dire attaque : dans la majorité des cas, il manque simplement le fichier .prov ou la clé publique. Le message d'erreur permet de trancher, et c'est ce tri qu'il faut faire avant toute autre chose. Une seule des trois situations impose de tout arrêter.

Erreur	Cause probable	Action
Error: could not find a valid signature	Fichier .prov manquant	Contacter l'auteur, télécharger le .prov
Error: signature verification failed	Chart modifié ou mauvaise clé	Ne pas installer, télécharger depuis source officielle
Error: key not found	Clé publique non importée	Importer la clé de l'auteur

Glissez pour voir

Vérification échouée = danger

Si helm verify échoue, n'installez jamais le chart. Soit il a été altéré, soit vous n'avez pas la bonne clé. Dans les deux cas, la seule conduite est d'investiguer avant de continuer : un chart qu'on installe « pour voir » est déjà installé.

---

Distribuer la clé publique

Toute la chaîne repose sur ce point : si vos utilisateurs récupèrent la clé publique au même endroit que le chart, un attaquant qui contrôle le dépôt remplace les deux et la vérification réussit sur un chart falsifié. La clé doit donc emprunter un canal distinct de celui des artefacts. Publiez aussi son empreinte là où votre identité est déjà établie.

Options de distribution

Aucune méthode n'est parfaite : elles se distinguent par le type de compromission qu'elles rendent difficile. En pratique, la combinaison de deux canaux vaut mieux qu'un seul, même excellent.

Méthode	Avantages	Inconvénients
README du repo	Simple, visible	Peut être modifié par un attaquant
Keyserver public	Standard GPG, décentralisé	Peut contenir des clés abandonnées
Site web HTTPS	Contrôle total, HTTPS = TLS	Nécessite infra web
DNS (DANE)	Très sécurisé	Complexe à configurer

Glissez pour voir

Publication sur keyserver

L'envoi sur un serveur de clés public est irréversible : une clé publiée ne peut plus être retirée, seulement révoquée par un certificat de révocation que vous devez générer à l'avance, tant que vous détenez encore la clé.

# Envoyer la clé sur un keyserver public
gpg --keyserver keyserver.ubuntu.com --send-keys ABCD1234EFGH5678

Récupération par les utilisateurs

Récupérer une clé par son identifiant ne la rend pas digne de confiance pour autant : n'importe qui peut téléverser une clé portant le nom de votre projet. Comparez l'empreinte obtenue avec celle publiée par l'auteur avant de l'utiliser.

# Télécharger la clé depuis un keyserver
gpg --keyserver keyserver.ubuntu.com --recv-keys ABCD1234EFGH5678

---

Workflow complet en CI/CD

Automatiser la signature suppose de donner au pipeline l'accès à une clé privée, donc de la stocker comme secret masqué et jamais dans le dépôt. Le job ci-dessous importe la clé, reconstitue le trousseau au format attendu par Helm, puis empaquette et signe. Le point de vigilance est en fin de job : helm push publie l'archive, pas le .prov, qui doit être transmis à part, sous peine de livrer un chart que personne ne pourra vérifier.

.gitlab-ci.yml

variables:
  GPG_KEY_ID: "ABCD1234EFGH5678"

package-and-sign:
  stage: build
  script:
    # Importer la clé privée depuis les secrets
    - echo "$GPG_PRIVATE_KEY" | gpg --import
    - gpg --export-secret-keys > ~/.gnupg/secring.gpg

    # Packager et signer
    - helm package ./charts/my-chart --sign --key "$GPG_KEY_ID" --keyring ~/.gnupg/secring.gpg

    # Publier chart + provenance
    - helm push my-chart-*.tgz oci://registry.example.com/charts
    # Note: le .prov doit être publié séparément ou avec le chart
  artifacts:
    paths:
      - "*.tgz"
      - "*.tgz.prov"

---

Limites et alternatives

La signature GPG native de Helm date d'une époque où les charts se distribuaient par HTTP, avec un index.yaml et des archives posées sur un serveur web. Le passage aux registres OCI a changé la donne : l'artefact et ses métadonnées y vivent ensemble, ce que le modèle du fichier .prov séparé ne sait pas exploiter.

Limites de la signature Helm native

Ces quatre limites relèvent de la conception, pas d'un défaut d'implémentation : aucune ne se corrige par une option. Elles indiquent quand il faut regarder ailleurs, plutôt que chercher un réglage qui n'existe pas.

Limitation	Impact
GPG uniquement	Pas de support natif pour d'autres systèmes (Cosign, Notation)
.prov séparé	Doit être distribué en plus du chart
Pas d'intégration OCI native	Le .prov ne fait pas partie de l'artefact OCI
Gestion des clés manuelle	Rotation, révocation à gérer vous-même

Glissez pour voir

Alternative moderne : Cosign + OCI

Cosign (projet Sigstore) permet de signer des artefacts OCI (y compris des charts Helm) :

# Signer un chart OCI avec Cosign
cosign sign oci://registry.example.com/charts/my-chart:1.2.3

# Vérifier
cosign verify oci://registry.example.com/charts/my-chart:1.2.3

Trois avantages expliquent pourquoi Cosign s'impose sur les registres OCI :

• La signature est intégrée à l'artefact, sans fichier séparé à transmettre
• Il accepte les clés éphémères, la signature keyless s'appuyant sur une identité OIDC
• Son intégration aux registres est native, là où le .prov reste un fichier à côté

Pour un nouveau projet qui publie en OCI, privilégiez Cosign. Il signe l'artefact dans le registre plutôt qu'un fichier posé à côté, ce qui supprime le problème du .prov qu'on oublie de transporter, et il s'intègre à l'outillage de chaîne d'approvisionnement déjà en place pour les images.

La signature GPG native de Helm garde sa place pour les dépôts HTTP classiques et les environnements sans registre OCI, qui restent nombreux en interne. Ce n'est pas une technologie dépassée, c'est une technologie dont le périmètre s'est réduit.

---

Lab C2, Signer et vérifier un chart

Objectif : Créer une clé GPG, signer un chart, publier chart + provenance, vérifier l'intégrité avant installation.

Ce lab s'exécute intégralement en local, sans cluster ni registre. Son intérêt tient à l'étape 5 : vous altérez volontairement le chart signé pour constater que helm verify le détecte, ce qui vaut mieux que de le lire. La clé créée expire au bout d'un jour et est générée sans passphrase pour ne pas bloquer le script, ce qui la rend impropre à tout autre usage.

1. Créer une clé de test

   # Clé rapide pour le lab (pas pour production)
   gpg --batch --gen-key <<EOF
   Key-Type: RSA
   Key-Length: 2048
   Name-Real: Helm Lab
   Name-Email: helm-lab@local
   Expire-Date: 1d
   %no-protection
   %commit
   EOF
   
   # Récupérer l'ID
   GPG_KEY=$(gpg --list-secret-keys --keyid-format LONG | grep sec | awk '{print $2}' | cut -d'/' -f2 | head -1)
   echo "Key ID: $GPG_KEY"

2. Exporter le keyring

   gpg --export-secret-keys > ~/.gnupg/secring.gpg

3. Créer et signer un chart

   helm create lab-signed-chart
   helm package lab-signed-chart --sign --key "Helm Lab" --keyring ~/.gnupg/secring.gpg

4. Vérifier la signature

   # La clé publique est déjà importée (on l'a créée localement)
   helm verify lab-signed-chart-0.1.0.tgz

5. Simuler une altération

   # Décompresser le chart
   tar -xzf lab-signed-chart-0.1.0.tgz
   
   # Modifier un fichier
   echo "# Malicious change" >> lab-signed-chart/values.yaml
   
   # Recompresser
   tar -czf lab-signed-chart-0.1.0.tgz lab-signed-chart
   
   # Tenter de vérifier → doit échouer
   helm verify lab-signed-chart-0.1.0.tgz

6. Nettoyer

   rm -rf lab-signed-chart lab-signed-chart-*.tgz*
   gpg --delete-secret-and-public-key "Helm Lab"

Critères de réussite :

• Clé GPG créée
• Chart signé avec .prov généré
• helm verify réussit sur le chart original
• helm verify échoue sur le chart altéré

---

À retenir

• Provenance = garantie d'intégrité et d'authenticité via signature cryptographique
• helm package --sign = créer le chart + fichier .prov
• helm verify = vérifier la signature avant installation
• Clé privée = secrète, protégée, jamais partagée
• Clé publique = distribuée aux utilisateurs pour vérification
• Alternative moderne : Cosign pour les artefacts OCI

---

Contrôle de connaissances

Quatre questions sur la provenance : ce que contient un fichier .prov, ce que verify détecte réellement, et la limite qu'aucune signature ne franchit.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

4 questions

5 min.

80% requis

Informations

• Le chronomètre démarre au clic sur Démarrer
• Questions à choix multiples, vrai/faux et réponses courtes
• Vous pouvez naviguer entre les questions
• Les résultats détaillés sont affichés à la fin

Démarrer le quiz

Lance le quiz et démarre le chronomètre

Pour aller plus loin

• Packaging et promotion en CI/CD : Signer dans le pipeline plutôt que sur un poste de développement.
• Migrer vers Helm v4 : Ce que la version 4 change pour la provenance et la vérification.

×

📖 Voir la documentation →