Registres et confiance des images

Les registres fournissent les images qu’exécutent les nœuds Docker et les artefacts que publient les Build Workers. Opfield sépare les identifiants de registres et les décisions d’accès de la configuration des charges de travail qui consomment une image. Cette séparation permet à un opérateur de faire tourner l’accès à un registre sans exposer de mot de passe dans la définition d’un Container, d’un Deployment ou d’une source.

Définir la politique de confiance des images

La décision clé ne porte pas seulement sur l’endroit où une image est stockée, mais sur les preuves exigées avant qu’elle puisse s’exécuter. Une politique pratique identifie les registres approuvés, les empreintes immuables exigées, qui peut publier, le seuil de vulnérabilités, les responsables des identifiants et la durée de conservation des artefacts de retour arrière.

Les équipes applicatives choisissent l’artefact logiciel. Les responsables de la sécurité définissent l’admission et le périmètre des identifiants. Les responsables de la plateforme assurent la disponibilité des registres et l’accès des nœuds cibles. Opfield enregistre les correspondances, les secrets, la provenance des builds et les résultats des politiques, mais il ne rend pas une image inconnue digne de confiance simplement parce qu’une récupération a réussi.

Le succès signifie que la charge de travail déployée utilise l’empreinte revue, que chaque nœud requis peut la récupérer via un chemin d’identifiants approuvé, et que l’artefact précédent réputé sain reste disponible pendant la fenêtre de retour arrière.

Configurer un accès de confiance

Stockez les identifiants des registres privés dans Opfield et limitez-les au chemin de build ou d’exécution prévu. Ne configurez une origine de service de jetons de confiance distincte que lorsque le registre délègue intentionnellement l’authentification Bearer à ce service. Confirmez le point de terminaison du registre, l’accès aux dépôts et la confiance dans les certificats avant un déploiement en production.

Ne placez jamais de mots de passe de registre dans les références d’images, les URL Git, les arguments de build, les journaux, les noms d’archives ou les captures d’écran. Si l’authentification échoue, diagnostiquez l’identifiant du registre, la permission sur le dépôt, la configuration du service de jetons et la joignabilité du nœud cible plutôt que de redémarrer la charge de travail à répétition.

Comportement du registre interne

Le registre Distribution interne d’Opfield stocke les artefacts de build approuvés par empreinte immuable. Il conserve les artefacts nécessaires aux charges de travail actives, aux slots de retour arrière, aux opérations en cours, aux références épinglées et aux builds réussis récents. Il ne nécessite pas de domaine public pour l’usage interne d’Opfield. Le registre signale le stockage réellement utilisé par son volume, actualisé environ toutes les 10 minutes.

La présence d’une image dans le registre interne n’en fait pas une version publique. Une charge de travail doit toujours être configurée pour utiliser l’empreinte, la récupérer avec succès sur son nœud cible et passer sa vérification opérationnelle.

Accès facultatif depuis des clients Docker externes

L’accès depuis des clients Docker externes est un droit et une configuration d’ingress distincts, et fonctionne sur les nœuds Ingress nginx standard. Il nécessite un placement nginx sélectionné, un domaine, un certificat TLS et un jeton limité à un dépôt ou à une action. Après la fin d’une période de grâce de licence, le point d’entrée externe et ses paramètres sont conservés, mais le point de terminaison des jetons n’émet plus de nouveaux jetons jusqu’au renouvellement du plan. Chaque demande de jeton revérifie l’autorisation et les droits actuels ; la révocation de l’un ou de l’autre prend donc effet pour les accès suivants.

N’activez l’accès externe que lorsqu’un véritable processus client l’exige. Validez TLS, l’authentification et les permissions minimales sur les dépôts et actions avec un client hors production avant de vous y appuyer pour l’automatisation. Retirer la configuration d’ingress arrête l’accès des clients, mais ne supprime pas les artefacts conservés en interne.

Conseils en cas d’incident et de nettoyage

Pour une récupération en échec, confirmez d’abord l’empreinte exacte de l’image, la correspondance de registre, le périmètre de l’identifiant et le chemin réseau du nœud. Pour une image inattendue, comparez son empreinte avec l’enregistrement du build approuvé plutôt que de vous fier à un tag. Avant de retirer une configuration de registre, identifiez les charges de travail et les candidats au retour arrière qui en ont encore besoin ; faites-les d’abord passer sur une alternative approuvée.

Cycle de vie des identifiants

Préférez des identifiants limités à un dépôt et à une action plutôt que des jetons d’administration de registre étendus. Consignez un responsable et un processus de rotation pour chaque identifiant, et testez le remplaçant avant de révoquer l’ancienne valeur lorsque la livraison continue en dépend. La révocation doit tenir compte séparément des Build Workers, des nœuds Docker et des clients externes, car ils peuvent utiliser des chemins d’accès différents.

Si un identifiant est exposé, révoquez-le auprès du registre, remplacez-le dans Opfield et identifiez les builds ou récupérations effectués pendant la fenêtre d’exposition. Faire tourner uniquement la copie d’Opfield n’invalide pas le secret d’origine chez le fournisseur. Examinez les journaux à la recherche de dépôts ou d’empreintes inattendus sans copier d’en-têtes contenant des secrets dans l’enregistrement d’incident.

Détails pour l’opérateur : échecs de récupération et conservation

Pour les échecs d’authentification, distinguez la joignabilité DNS/TLS, la correspondance de registre, le refus de l’identifiant, l’origine du service de jetons, la permission sur le dépôt et le manifeste manquant. Testez le dépôt et l’empreinte exacts depuis le chemin d’exécution concerné plutôt que depuis un poste d’administrateur sans rapport.

Avant d’élaguer le registre interne ou de retirer l’accès externe, identifiez les empreintes des charges de travail actives, les slots de retour arrière des Deployments, les builds en cours, les artefacts épinglés et les versions récentes réputées saines. Si un artefact requis a été supprimé, republiez-le ou reconstruisez-le à partir de la révision source vérifiée avant de modifier la charge de travail. Ne le remplacez pas par un tag non vérifié qui porte par hasard le même nom.