Filtres de contenu (autorisation/blocage de paquets)

Les filtres de contenu permettent de bloquer ou d'autoriser des paquets par nom, sur une base par distribution — par exemple, pour empêcher tout paquet correspondant à *-internal-* d'atteindre une distribution destinée au public. Il s'agit d'une porte de contrôle sur les noms de paquets, évaluée pour chaque utilisateur quel que soit son rôle ; ce n'est pas une couche de contrôle d'accès. Pour comprendre comment cela s'articule avec distribution_access/machine_access, voir Le modèle RBAC.

---

1. Prérequis

• Le rôle admin pour créer, supprimer ou balayer (« sweep ») des règles de filtre.
• Tout utilisateur authentifié disposant d'un accès en lecture à la distribution (sous réserve de distribution_access si configuré) peut lister les règles et lancer un aperçu.
• Décidez à l'avance votre stratégie de correspondance : exact (correspondance littérale du nom), glob (jokers façon shell via fnmatch, ex. *-internal-*), ou regex (expression régulière Python).

Jamais rétroactif par lui-même

Ajouter ou modifier une règle n'a aucun effet sur les paquets déjà publiés dans la distribution. Les nouveaux uploads/imports/promotions sont évalués selon les règles actuelles à partir de ce moment ; le contenu existant n'est affecté que si vous lancez explicitement un balayage (section 5).

---

2. Vérifier les règles actuelles

curl -s http://repod.example.com:8000/api/v1/distributions/jammy/filters \
  -H "Authorization: Bearer repod_xxxxxxxxxxxxxxxx" | jq .

Un tableau rules vide signifie que la distribution accepte actuellement n'importe quel nom de paquet.

---

3. Ajouter une règle

curl -s -X POST http://repod.example.com:8000/api/v1/distributions/jammy/filters \
  -H "Authorization: Bearer repod_xxxxxxxxxxxxxxxx" \
  -H "Content-Type: application/json" \
  -d '{
    "rule_type": "deny",
    "match_type": "glob",
    "pattern": "*-internal-*",
    "description": "Block anything with -internal- in the name from this public distribution"
  }' | jq .

Champ	Valeurs	Signification
rule_type	allow | deny	Indique si la règle autorise ou bloque un nom correspondant
match_type	exact | glob | regex	Comment pattern est évalué
pattern	chaîne	Le motif de nom à faire correspondre
description	chaîne (optionnel)	Note libre, vide par défaut

Réponse (201) :

{
  "rule": {
    "id": "...",
    "codename": "jammy",
    "rule_type": "deny",
    "match_type": "glob",
    "pattern": "*-internal-*",
    "description": "Block anything with -internal- in the name from this public distribution",
    "created_by": "admin",
    "created_at": "..."
  }
}

Ordre d'évaluation (façon Katello)

1. Si au moins une règle allow existe pour la distribution, un nom de paquet doit correspondre à au moins l'une d'entre elles, sinon il est rejeté.
2. Quel que soit le résultat de l'autorisation, une règle deny correspondante l'emporte toujours — un nom correspondant à la fois à une règle allow et à une règle deny est rejeté.

Une distribution ne comportant que des règles deny et aucune règle allow se comporte comme une simple liste noire : tout est accepté sauf ce qui correspond à une règle deny.

Exemple complet — bloquer tout nom *-internal-* d'une distribution publique :

Le POST ci-dessus fait déjà exactement cela. À partir de ce moment :

• POST /upload/ pour un paquet nommé myapp-internal-tools ciblant jammy est rejeté avant même que le fichier n'atteigne pool/.
• POST /import/fetch pour un nom correspondant est rejeté avant même que l'artefact ne soit téléchargé.
• POST /distributions/promote avec to_dist: "jammy" et un nom de paquet correspondant est rejeté — le filtre est conditionné sur la distribution de destination.
• Les paquets déjà présents dans jammy avant l'ajout de la règle sont inaffectés, jusqu'à ce que vous lanciez un balayage.

---

4. Prévisualiser une règle avant de la valider

Testez comment un nom de paquet serait évalué au regard des règles actuelles de la distribution, sans rien modifier :

curl -s -X POST http://repod.example.com:8000/api/v1/distributions/jammy/filters/preview \
  -H "Authorization: Bearer repod_xxxxxxxxxxxxxxxx" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "myapp-internal-tools",
    "version": ""
  }' | jq .

version est optionnel et vaut une chaîne vide par défaut. C'est la même logique d'évaluation que celle utilisée au moment de l'upload/import/promotion — utile à la fois pour tester une règle avant de l'enregistrer, et pour expliquer après coup pourquoi un upload réel a été rejeté.

---

5. Balayer le contenu existant (suppression rétroactive)

Les filtres de contenu ne touchent jamais automatiquement les paquets existants. Pour appliquer les règles actuelles à ce qui est déjà publié dans une distribution :

# Simulation (par défaut) — liste ce qui serait supprimé, ne change rien
curl -s -X POST "http://repod.example.com:8000/api/v1/distributions/jammy/filters/sweep?dry_run=true" \
  -H "Authorization: Bearer repod_xxxxxxxxxxxxxxxx" | jq .

# Supprimer réellement les paquets non conformes, uniquement de cette distribution
curl -s -X POST "http://repod.example.com:8000/api/v1/distributions/jammy/filters/sweep?dry_run=false" \
  -H "Authorization: Bearer repod_xxxxxxxxxxxxxxxx" | jq .

dry_run vaut true par défaut — vous devez explicitement passer dry_run=false pour supprimer quoi que ce soit. Le balayage est limité à la seule distribution sur laquelle vous l'avez appelé ; un paquet présent dans plusieurs distributions n'est retiré que de celle que vous avez balayée.

Le balayage est une action délibérée et explicite

Il n'y a pas de re-balayage automatique lorsqu'une règle change. Si vous avez besoin de nettoyer le contenu existant après avoir ajouté une règle deny, vous devez lancer le balayage vous-même — c'est voulu, afin de garder les changements de filtres prévisibles et auditables.

---

6. Supprimer une règle

curl -s -X DELETE http://repod.example.com:8000/api/v1/distributions/jammy/filters/<rule_id> \
  -H "Authorization: Bearer repod_xxxxxxxxxxxxxxxx"

Renvoie 204 en cas de succès, 404 si la règle n'existe pas. Supprimer la dernière règle rouvre la distribution à n'importe quel nom de paquet ; cela ne restaure pas les paquets déjà supprimés par un balayage précédent.

---

7. Vérifier que ça a fonctionné

# Confirmer que la règle est active
curl -s http://repod.example.com:8000/api/v1/distributions/jammy/filters \
  -H "Authorization: Bearer repod_xxxxxxxxxxxxxxxx" | jq '.rules'

# Prévisualiser un nom qui devrait être bloqué
curl -s -X POST http://repod.example.com:8000/api/v1/distributions/jammy/filters/preview \
  -H "Authorization: Bearer repod_xxxxxxxxxxxxxxxx" \
  -H "Content-Type: application/json" \
  -d '{"name": "myapp-internal-tools"}' | jq .
# → {"allowed": false, "reason": "...", "matched_rule": {...}}

# Prévisualiser un nom qui devrait passer
curl -s -X POST http://repod.example.com:8000/api/v1/distributions/jammy/filters/preview \
  -H "Authorization: Bearer repod_xxxxxxxxxxxxxxxx" \
  -H "Content-Type: application/json" \
  -d '{"name": "myapp-public"}' | jq .
# → {"allowed": true, ...}

Confirmez ensuite de bout en bout en tentant un véritable upload d'un nom bloqué vers jammy — il doit échouer à la validation avant que le paquet n'atteigne pool/, avec le motif de rejet correspondant à ce que l'aperçu avait indiqué.