Navin Trusted Hub

La page Navin Trusted Hub (/admin/hub) montre les paquets signés du Hub, leurs analyses et les versions installées. Elle nécessite system:read ; les réglages et la synchronisation nécessitent settings:manage.

Ce que montre l'écran

Élément	Contenu
Synchronisation	Dernière synchronisation ou Jamais synchronisé
Paquets	chaque paquet avec ses versions, les versions Installé et les Analyses (réussie ou échouée par outil)

Actions

Bouton	Effet	Permission
Réglages, Jeton d'accès, Enregistrer	adresse, identifiant client, clés épinglées, application stricte et jeton du Hub ; un jeton vide conserve celui enregistré	settings:manage
Synchroniser	télécharge et vérifie les métadonnées signées du Hub	settings:manage
Importer une copie hors ligne	importe un document de métadonnées JSON du Hub copié à la main	settings:manage

Tâches courantes

1. Travailler hors ligne. Exportez les métadonnées sur un hôte connecté, puis Importer une copie hors ligne ici.

Identité explicite du registre (migration TRT-12)

hub.expected_hub est vide par défaut. Aucun remplissage automatique : toute ingestion en ligne/hors ligne est refusée tant qu’un administrateur n’a pas épinglé l’identité exacte signed.hub, même si l’application stricte est désactivée. Ce n’est pas l’URL API : registry.example.org est un exemple, pas une valeur de déploiement. Confirmez l’identité auprès de votre administrateur Hub de confiance et vérifiez indépendamment la clé de signature ; ne la déduisez jamais d’une URL ou d’un document non fiable.

Avant la mise à niveau, relevez l’identité actuelle et le seuil anti-retour arrière. Après mise à niveau, renseignez l’identité confirmée dans les réglages Hub (obligatoire dans l’interface), puis réimportez/synchronisez un document signé de version identique ou supérieure. Une modification de politique invalide atomiquement le cache d’autorisation sans supprimer le seuil de version ni son empreinte. Restaurer l’identité précédente ne réactive pas le cache : une nouvelle vérification de signature est nécessaire.

Si nm.hub_state.hub diffère, une nouvelle identité non vide et l’ingestion sont refusées, même pour une version supérieure. Le transfert d’autorité n’est pas implémenté : arrêtez-vous et obtenez une politique de migration explicitement approuvée par l’administrateur hors de ce flux. Ne supprimez/réinitialisez pas l’état pour contourner ce refus. Une identité vide via API désactive l’ingestion et invalide le cache tout en conservant le seuil. Cette version ne modifie aucun réglage en production.

Inventaire des fichiers et preuves vérifiées (TRT-04, TRT-08)

Avec « Installer uniquement les paquets approuvés par le Hub » (hub.enforce), un binaire, une archive ou une wheel n’est livré que si son sha256 est le digest d’une cible approuvée ou l’un de ses files[].digest. Le Hub produit désormais cet inventaire lui-même : il le dérive du manifeste OCI dont le sha256 est le digest de la version (une entrée par couche, nommée par son annotation org.opencontainers.image.title), plus les fichiers trouvés dans une couche archive et attestés par l’identité de scanner. Une liste fournie par l’émetteur n’est jamais retenue. L’inventaire est signé avec le document et repris dans les révocations : un fichier révoqué est refusé, même si une autre cible liste le même digest.

Chaque analyse d’une cible porte keyid, la clé de scanner qui l’a attestée, et cosign contient la charge utile Cosign et sa signature, vérifiables hors ligne avec la clé publique Cosign de Navinspire.

Une version publiée avant cette correction n’a pas d’inventaire : sous hub.enforce, ses binaires et wheels restent refusés (hub_artifact_not_approved). Demandez à l’administrateur du Hub une nouvelle version (analyse attestée et inventaire), puis synchronisez ou réimportez le document. Le Manager n’a rien à changer : il lisait déjà files[].digest.