Signer les artefacts Pulp avec Cosign et GPG

Ce guide signe une image de conteneur avec Cosign puis la vérifie, le tout hébergé par Pulp, et montre comment déclarer un signing service GPG pour signer manifestes, RPM et collections Ansible côté serveur. Public visé : équipes qui veulent prouver l'intégrité et la provenance de leurs artefacts. Prérequis : une instance Pulp avec le registre de conteneurs actif (voir Installer Pulp), plus cosign, podman et gpg sur la machine cliente.

Signer un artefact, c'est apposer une preuve cryptographique qu'il n'a pas été altéré depuis sa production et qu'il vient bien de vous. Pulp gère la signature de deux façons complémentaires : les signatures Cosign/Sigstore pour les images de conteneurs (côté client, Pulp héberge), et les signing services GPG pour signer manifestes, métadonnées RPM et collections Ansible côté serveur.

Ce que vous allez apprendre

• Distinguer signature Cosign et signing service GPG.
• Signer une image de conteneur avec Cosign et la stocker dans Pulp.
• Vérifier une signature Cosign servie par Pulp.
• Déclarer un manifest signing service GPG et l'attacher à un dépôt.

Deux modèles de signature

Pulp ne signe pas tout de la même manière selon le type de contenu. Comprendre la différence évite de chercher une commande qui n'existe pas.

Modèle	Contenu	Où la signature est produite
Cosign / Sigstore	Images de conteneurs	Côté client (cosign, podman), Pulp héberge la signature
Signing service GPG	Manifestes conteneurs, métadonnées RPM, collections Ansible	Côté serveur Pulp, via un script de signature

Glissez pour voir

Le premier modèle s'appuie sur l'écosystème Sigstore : comme Pulp est un registre OCI, il stocke nativement une signature Cosign en tant qu'image OCI à côté de l'image signée. Le second modèle s'appuie sur GPG et un script exécuté par Pulp au moment de la publication.

Signer une image avec Cosign

Le scénario : vous poussez une image dans Pulp, vous la signez avec Cosign (le signataire du projet Sigstore), et n'importe quel consommateur peut ensuite vérifier la signature. Pulp héberge la signature sans configuration serveur particulière. Si Cosign vous est nouveau, le guide Cosign dédié détaille la génération de clés et le rôle de Rekor.

1. Pousser une image dans un dépôt hébergé par Pulp :

   podman login pulp.exemple.com
   podman tag busybox:latest pulp.exemple.com/demo/busybox:latest
   podman push pulp.exemple.com/demo/busybox:latest

2. Générer une paire de clés Cosign (clé privée protégée par mot de passe) :

   cosign generate-key-pair

   La commande produit cosign.key (privée) et cosign.pub (publique). Conservez la clé privée dans un coffre-fort, jamais dans un dépôt Git.

3. Signer l'image dans Pulp. On s'authentifie auprès du registre, puis on signe par digest (plus sûr que par tag) :

   cosign login pulp.exemple.com -u admin -p "MotDePasse"
   cosign sign --key cosign.key pulp.exemple.com/demo/busybox:latest

   Cosign calcule le digest, signe, et pousse la signature dans Pulp sous un tag dédié de la forme sha256-<digest>.sig. C'est un objet OCI comme un autre, hébergé à côté de l'image.

TLS approuvé et journal de transparence

Ces commandes supposent le certificat de Pulp approuvé par le client (certificat public, ou CA auto-signée dans le magasin de confiance, voir Pulp en air-gapped). L'option --tlog-upload=false évite de publier dans le journal de transparence public Rekor, non joignable en réseau isolé. N'utilisez pas --allow-insecure-registry : approuvez la CA plutôt que de désactiver la vérification.

Vérifier une signature Cosign

La vérification prouve que l'image correspond bien à une signature émise par votre clé. Le consommateur n'a besoin que de la clé publique :

cosign verify --key cosign.pub pulp.exemple.com/demo/busybox:latest

La sortie confirme que les signatures ont été vérifiées avec la clé publique et affiche la charge utile, avec le type cosign container image signature et le digest de l'image. Une image non signée ou modifiée fait échouer la commande, ce qui permet de bloquer un déploiement dans un pipeline.

Signatures mirroir à la synchronisation

Quand Pulp synchronise un dépôt distant qui contient des signatures Cosign, il les mirroir automatiquement avec les images. Vous conservez ainsi la chaîne de confiance même sur un cache interne, sans re-signer.

Signer côté serveur avec un signing service GPG

Pour les manifestes de conteneurs, les métadonnées RPM et les collections Ansible, Pulp signe côté serveur via un signing service : un script que Pulp exécute, adossé à une clé GPG.

1. Écrire le script de signature. Pour un manifeste de conteneur, il invoque skopeo standalone-sign et renvoie le chemin de la signature au format JSON attendu par Pulp :

   #!/usr/bin/env bash
   MANIFEST_PATH=$1
   skopeo standalone-sign \
     "$MANIFEST_PATH" "$REFERENCE" "$PULP_SIGNING_KEY_FINGERPRINT" \
     --output "$SIG_PATH"
   if [ $? -eq 0 ]; then
     echo "{\"signature_path\": \"$SIG_PATH\"}"
   else
     exit 1
   fi

   Les variables REFERENCE, PULP_SIGNING_KEY_FINGERPRINT et SIG_PATH sont fournies par Pulp ; ne les renommez pas. La clé GPG doit être installée dans le trousseau de l'utilisateur pulp.

2. Déclarer le signing service avec la classe adaptée au contenu (ici les manifestes de conteneurs) :

   pulpcore-manager add-signing-service ma-signature \
     /var/lib/pulp/scripts/sign-manifest.sh \
     45ACE14E3EBB9BBA \
     --class container:ManifestSigningService

   Pulp valide le script à l'enregistrement, ce qui évite de sauvegarder un script cassé.

3. Attacher le service au dépôt via son champ manifest_signing_service. Les images publiées depuis ce dépôt sont alors signées automatiquement côté serveur.

La même mécanique pour RPM et Ansible

Le principe est identique pour les autres formats, seule la classe change : rpm:RpmPackageSigningService pour signer les métadonnées RPM, ansible:CollectionSigningService pour les collections. Chaque plugin expose son propre champ de dépôt pour rattacher le service.

Gérer les clés en sécurité

Une signature ne vaut que si sa clé privée reste secrète. Quelques réflexes non négociables :

• Jamais de clé privée dans Git ni dans une image : stockez-la dans un coffre-fort comme HashiCorp Vault.
• Protégez la clé Cosign par mot de passe (COSIGN_PASSWORD) et une clé GPG par passphrase.
• Publiez la clé publique largement : c'est elle qui permet la vérification, elle n'a pas à être secrète.
• Combinez avec un scan : signer prouve l'intégrité, pas l'absence de vulnérabilité. Enchaînez avec Trivy dans la CI.

À retenir

• Pulp signe de deux façons : Cosign/Sigstore pour les images (client), signing services GPG pour manifestes, RPM et collections (serveur).
• Une signature Cosign est stockée par Pulp comme objet OCI sous un tag sha256-<digest>.sig.
• cosign verify --key cosign.pub valide l'image ; un échec peut bloquer un déploiement.
• Pulp mirroir les signatures Cosign lors d'une synchronisation.
• Un signing service (add-signing-service) exécute un script GPG côté serveur, attaché au dépôt par son champ de signature.
• La clé privée ne quitte jamais un coffre-fort ; signer ne remplace pas le scan de vulnérabilités.

Prochaines étapes

Sécuriser Pulp RBAC, content-guards et filtres de synchronisation.

Registre de conteneurs et scan Trivy Héberger et scanner les images avant de les signer.

Cosign Approfondir la signature Sigstore et la vérification.

Présentation de Pulp Revenir au modèle de contenu et au positionnement.

×

📖 Voir la documentation →