Pulp comme registre de conteneurs et scan Trivy

Ce guide fait de Pulp un registre d'images de conteneurs : on met Docker Hub en cache via un pull-through, on tire une image à travers Pulp avec podman, puis on la scanne avec Trivy. Public visé : équipes qui veulent un registre OCI privé sans dépendre du rate limiting de Docker Hub, et ajouter un contrôle de sécurité. Prérequis : une instance Pulp avec l'authentification par jeton configurée (voir Installer Pulp), podman et trivy sur la machine cliente.

Le plugin pulp_container transforme Pulp en registre compatible OCI/Docker. Il sait héberger vos propres images, mais aussi jouer les caches transparents (pull-through) d'un registre amont : la première fois qu'un client demande une image, Pulp la récupère chez l'amont, la stocke, et la sert directement aux appels suivants.

Ce que vous allez apprendre

Configurer un cache pull-through vers Docker Hub.
Tirer une image à travers Pulp avec podman.
Scanner les images servies par Pulp avec Trivy.
Comprendre pourquoi ce contrôle se place dans la CI.

Prérequis : l'authentification par jeton

Le registre de conteneurs de Pulp exige une authentification par jeton (le mécanisme standard des registres Docker). Elle repose sur une paire de clés ES256 et sur le paramètre TOKEN_SERVER, à définir dans settings/settings.py :

CONTENT_ORIGIN = "https://pulp.exemple.com"
TOKEN_SERVER = "https://pulp.exemple.com/token/"
TOKEN_SIGNATURE_ALGORITHM = "ES256"
PUBLIC_KEY_PATH = "/etc/pulp/certs/token_public_key.pem"
PRIVATE_KEY_PATH = "/etc/pulp/certs/token_private_key.pem"

On génère la paire de clés dans le répertoire des certificats monté par le conteneur :

openssl ecparam -genkey -name prime256v1 -noout -out settings/certs/token_private_key.pem
openssl ec -in settings/certs/token_private_key.pem -pubout -out settings/certs/token_public_key.pem
podman restart pulp

Après redémarrage, un appel sur https://pulp.exemple.com/v2/ doit renvoyer 401 (et non 500) : c'est le signe que l'authentification par jeton est active et correctement configurée.

Configurer le cache pull-through vers Docker Hub

Le cache pull-through associe un remote (le registre amont) à une distribution (l'URL locale). Ces objets se créent aujourd'hui par l'API REST : la CLI ne les expose pas encore.

Créer le remote pull-through vers le registre Docker Hub :

curl -u admin:MOT_DE_PASSE \
  -X POST https://pulp.exemple.com/pulp/api/v3/remotes/container/pull-through/ \
  -H 'Content-Type: application/json' \
  -d '{"name":"dockerhub","url":"https://registry-1.docker.io"}'

Récupérer l'identifiant du remote créé :

RH=$(curl -s -u admin:MOT_DE_PASSE \
  "https://pulp.exemple.com/pulp/api/v3/remotes/container/pull-through/?name=dockerhub" \
  | python3 -c "import sys,json;print(json.load(sys.stdin)['results'][0]['pulp_href'])")

Créer la distribution qui expose ce cache sous le chemin dockerhub :

curl -u admin:MOT_DE_PASSE \
  -X POST https://pulp.exemple.com/pulp/api/v3/distributions/container/pull-through/ \
  -H 'Content-Type: application/json' \
  -d "{\"name\":\"dockerhub\",\"base_path\":\"dockerhub\",\"remote\":\"$RH\"}"

Tirer une image à travers Pulp

Le cache est prêt. On s'authentifie auprès du registre Pulp, puis on tire une image : Pulp la récupère chez Docker Hub à la volée, la met en cache et la sert.

podman login -u admin -p MOT_DE_PASSE pulp.exemple.com
podman pull pulp.exemple.com/dockerhub/library/alpine:3.14

Pulp crée automatiquement une distribution dockerhub/library/alpine pour l'image demandée. Les téléchargements suivants sont servis depuis le cache, sans retoucher Docker Hub, ce qui contourne le rate limiting et accélère vos pipelines.

Scanner les images avec Trivy

Héberger des images ne suffit pas : il faut vérifier leurs vulnérabilités. C'est là que se construit le contrôle de sécurité que Pulp n'assure pas nativement. Trivy scanne une image directement à l'adresse servie par Pulp :

trivy image --scanners vuln --severity HIGH,CRITICAL \
  pulp.exemple.com/dockerhub/library/alpine:3.14

Trivy tire l'image via Pulp, analyse ses paquets et liste les CVE. Une image sans gestionnaire de paquets (comme busybox) ne renvoie rien à analyser ; une image à base de distribution (Alpine, Debian) révèle son état réel.

Placer le scan dans la CI, pas dans Pulp

Le bon endroit pour ce contrôle est la CI/CD, pas le registre. Le schéma robuste est le suivant :

Le pipeline tire l'image candidate depuis Pulp.
Trivy la scanne ; le job échoue si une CVE critique est présente (trivy image --exit-code 1 --severity CRITICAL).
Seule une image validée est promue vers un dépôt de production dans Pulp.

Ainsi, Pulp stocke et distribue, tandis que Trivy décide ce qui passe. Cette séparation reproduit, avec des briques libres, ce que Nexus Firewall ou Artifactory Xray facturent comme fonctionnalité intégrée.

À retenir

Le plugin pulp_container fait de Pulp un registre OCI capable d'héberger et de mettre Docker Hub en cache.
Le registre exige une authentification par jeton (clés ES256 + TOKEN_SERVER) ; une erreur 500 sur /v2/ signale des réglages manquants.
Le cache pull-through se crée par l'API REST et contourne le rate limiting de Docker Hub.
Trivy scanne les images servies par Pulp ; le contrôle se place dans la CI, où il peut bloquer une image vulnérable.
Pulp stocke, Trivy décide : deux briques libres qui remplacent une fonction de curation payante.

Prochaines étapes

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

Trivy Maîtriser le scanner de vulnérabilités en CLI et en CI.

Harbor Comparer avec un registre OCI spécialisé conteneurs.

Publier et consommer des artefacts Revenir au cycle de vie général des artefacts.