Sécuriser Pulp : RBAC, content-guards et signature

Ce guide couvre les leviers de sécurité de Pulp : qui peut lire ou écrire (RBAC), qui peut télécharger (content-guards), ce qui entre dans vos dépôts (filtres), et comment garantir l'intégrité (signature). Public visé : administrateurs qui exposent Pulp à plusieurs équipes ou en production. Prérequis : une instance Pulp opérationnelle et la CLI configurée (voir Installer Pulp). Vous verrez aussi, sans détour, ce que Pulp ne fait pas nativement en matière de sécurité supply chain.

La sécurité d'un gestionnaire d'artefacts se joue sur trois questions : qui accède à quoi, ce qu'on laisse entrer, et peut-on faire confiance à ce qui est stocké. Pulp répond aux trois, mais à sa manière, avec des briques à assembler plutôt qu'un tableau de bord clé en main.

Ce que vous allez apprendre

• Restreindre les accès avec le RBAC et ses rôles fins.
• Protéger le téléchargement avec des content-guards.
• Filtrer ce qui entre via --includes et --excludes.
• Garantir l'intégrité avec la signature de contenu.
• Situer honnêtement Pulp face à la quarantaine de vulnérabilités.

Contrôler les accès avec le RBAC

Pulp intègre un contrôle d'accès basé sur les rôles (RBAC) très granulaire. Chaque plugin apporte ses propres rôles, ce qui permet d'autoriser une équipe sur les dépôts Python sans lui ouvrir les dépôts RPM. L'instance fournit plus de 160 rôles prédéfinis dès l'installation.

pulp role list --limit 5

Les rôles suivent une nomenclature explicite, par exemple python.pythonrepository_owner (tout pouvoir sur les dépôts Python) ou rpm.rpmremote_viewer (lecture seule des remotes RPM). On assigne un rôle à un utilisateur ou à un groupe, sur un objet précis ou globalement.

1. Créer un utilisateur applicatif dédié à une équipe ou un pipeline :

   pulp user create --username ci-python --password "MotDePasseCI"

2. Lui attribuer un rôle ciblé, ici la gestion des dépôts Python :

   pulp user role-assignment add \
     --username ci-python \
     --role "python.pythonrepository_owner" \
     --object ""

   L'objet vide ("") donne le rôle au niveau global ; on peut aussi le restreindre à un dépôt précis via son href. Le principe de moindre privilège s'applique : un pipeline ne reçoit que les droits dont il a besoin.

Protéger le téléchargement avec les content-guards

Le RBAC gouverne l'API. Pour contrôler qui télécharge le contenu distribué, Pulp utilise les content-guards, posés sur une distribution. Plusieurs types coexistent :

Content-guard	Contrôle	Cas d'usage
RBAC	Selon les rôles Pulp	Dépôt privé réservé à une équipe
Header	Un en-tête HTTP attendu	Filtrage par un proxy en amont
x509	Un certificat client	Accès par certificat mutuel (mTLS)
Composite	Combinaison des précédents	Politiques multi-critères

Glissez pour voir

Un content-guard RBAC posé sur une distribution transforme un dépôt public en dépôt authentifié : seuls les utilisateurs disposant du rôle adéquat obtiennent les fichiers. C'est le mécanisme d'interdiction d'accès au niveau de la diffusion.

RBAC pour l'API, content-guard pour le contenu

Retenez la séparation : le RBAC décide qui peut créer ou modifier un dépôt (plan de contrôle) ; le content-guard décide qui peut télécharger les artefacts (plan de données). Une distribution vraiment privée combine les deux.

Filtrer ce qui entre dans vos dépôts

La première ligne de défense supply chain est de ne pas mirroir n'importe quoi. Les remotes acceptent des filtres --includes et --excludes qui définissent une liste blanche ou noire de paquets à synchroniser.

pulp python remote create \
  --name pypi-maitrise \
  --url https://pypi.org/ \
  --includes '["requests", "urllib3", "certifi"]' \
  --excludes '["requests<2.31.0"]'

Ici, seuls trois paquets sont miroités, et les versions vulnérables de requests (avant la 2.31.0) sont exclues du dépôt. Vous maîtrisez ainsi l'inventaire exact que vos machines peuvent installer, au lieu de relayer tout l'amont.

Garantir l'intégrité avec la signature

Pour prouver qu'un artefact n'a pas été altéré, Pulp s'appuie sur des signing services : des services de signature déclarés dans l'instance, adossés à une clé GPG ou à Sigstore/cosign selon le plugin.

pulp signing-service list

Une fois un service de signature déclaré, plusieurs plugins l'exploitent : pulp_rpm signe les métadonnées du dépôt, pulp_container vérifie les signatures des images à la synchronisation et peut refuser un manifeste non signé. Combinée au filtrage à l'entrée et au scan Trivy, la signature ferme la chaîne de confiance. La mise en oeuvre complète, avec Cosign pour les images et un signing service GPG pour manifestes, RPM et collections, est détaillée dans le guide Signer les artefacts Pulp.

Aucun service de signature par défaut

L'instance ne contient aucun signing service au démarrage : c'est à vous de déclarer votre clé et le script de signature. Tant que ce n'est pas fait, les dépôts sont servis sans signature ; ne considérez donc pas la signature comme acquise avant de l'avoir configurée.

Le versionnement immuable, filet de sécurité

Chaque synchronisation ou upload crée une version de dépôt immuable. Une distribution pointe vers une version précise : en cas de paquet compromis publié par erreur, vous revenez à la version précédente en une commande, sans restauration de sauvegarde. Cette traçabilité native est un atout de sécurité souvent sous-estimé.

Ce que Pulp ne fait pas : la quarantaine de vulnérabilités

Soyons clairs pour éviter une fausse attente : Pulp n'embarque pas de mise en quarantaine automatique des paquets vulnérables. Il n'existe pas d'équivalent natif au pare-feu applicatif de Nexus (blocage d'un composant sur son score CVE) ni à la curation d'Artifactory Xray.

Pulp fournit les briques pour construire cette garantie, mais c'est vous qui assemblez la politique :

• Filtrer à l'entrée avec --includes / --excludes.
• Scanner avec un outil externe comme Trivy dans la CI, en bloquant la promotion d'un artefact vulnérable.
• Promouvoir uniquement le contenu validé vers un dépôt de production.
• Restreindre l'accès avec le RBAC et les content-guards.

Ce modèle demande plus de travail d'intégration qu'une solution commerciale, mais il repose entièrement sur des outils libres et reste totalement sous votre contrôle.

Ajouter un firewall d'artefacts en amont

Pour se rapprocher d'une vraie admission control, on peut placer un firewall d'artefacts comme Varnish Orca devant Pulp. Orca est un virtual registry agnostique : son backend (remotes.url) accepte n'importe quel registre HTTP, Pulp compris. Le flux devient client -> Orca (décision allow/deny/quarantine) -> Pulp.

En lab, Orca proxifie bien Pulp (index PyPI et téléchargement d'artefacts servis à travers Orca). Le montage le plus direct concerne le registre de conteneurs (/v2/ à la racine, comme un registre OCI standard) ; pour PyPI, l'enveloppe de redirection d'Orca demande un alignement de CONTENT_ORIGIN. La décision de blocage elle-même reste une fonctionnalité Premium d'Orca.

À retenir

• Le RBAC de Pulp offre plus de 160 rôles fins, par plugin, pour appliquer le moindre privilège.
• Les content-guards (RBAC, header, x509, composite) contrôlent qui télécharge le contenu distribué.
• Les filtres --includes / --excludes maîtrisent ce qui entre dans vos dépôts.
• Les signing services signent les métadonnées et vérifient les images, mais rien n'est signé par défaut.
• Pulp n'a pas de quarantaine CVE native : on la construit avec un scanner externe et une politique de promotion.

Prochaines étapes

Registre de conteneurs et scan Trivy Mettre en place le scan des images dans la CI.

Trivy Le scanner à brancher pour la décision de sécurité.

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

Sécuriser la supply chain logicielle La démarche globale au-delà du dépôt d'artefacts.

×

📖 Voir la documentation →