Aller au contenu

Stocker les artefacts

Un registre interne d'artefacts est le coffre-fort de la chaîne logicielle. Il stocke les images conteneur, les charts Helm et les sorties de build produites par la CI/CD, et les met a disposition des environnements de déploiement de manière controlee.

Pourquoi un registre interne

Provenance des images

Sans registre interne, les équipes tirent des images depuis Docker Hub ou d'autres registres publics sans garantie d'intégrité. Un registre interne permet de :

  • Controler la provenance : seules les images construites par la CI/CD interne sont autorisees en production
  • Signer les artefacts : chaque image est signee cryptographiquement (Cosign/Sigstore) pour prouver son origine
  • Attacher des metadonnees : SBOM, rapports de scan de vulnerabilites, attestations de build

Scan de vulnerabilites

Un registre interne integre un scanner (Trivy, Clair) qui analyse chaque image poussee :

graph LR
    Push["CI/CD push image"] --> Registre --> Scan["Scan automatique"] --> Rapport["Rapport CVE"]
    Rapport --> Check{"Critical ?"}
    Check -->|Oui| Block["Bloquer le deploiement"]
    Check -->|Non| Available["Image disponible"]

Contrôle d'accès

Le registre applique un RBAC fin :

Besoin Mécanisme
Équipe A ne voit pas équipe B Projets prives, rôles membres
CI/CD pousse sans mot de passe humain Robot accounts avec scope limite
Production ne tire que du signe Admission control (OPA/Gatekeeper)
Auditeurs lisent les logs Rôle auditeur en lecture seule

Déploiements air-gapped

Dans les environnements deconnectes d'Internet (zones classifiees, edge industriel), le registre interne est la seule source d'images. La réplication entre registres permet de synchroniser les artefacts vers ces environnements isoles.

Classification

Aspect Niveau
Données manipulees Confidentiel (images contenant du code proprietaire et configs)
Zone de déploiement Chaîne logicielle
Chiffrement TLS obligatoire, stockage chiffre (S3/MinIO)

Les images contiennent du code

Une image conteneur embarque le code applicatif compile, les fichiers de configuration et parfois des secrets injectes au build. Elle doit etre traitee avec le même niveau de confidentialite que le code source.

Zone Chaîne logicielle

Le registre est positionne dans la zone Chaîne logicielle, accessible depuis :

  • CI/CD : pour pousser les images apres build
  • Production : pour tirer les images au déploiement
  • Développement : pour tirer les images de base et pousser les builds locaux (environnements de dev uniquement)
graph TD
    subgraph Zone["Zone Chaine logicielle"]
        SCM["SCM<br/>(Gitea)"]
        CICD["CI/CD<br/>(Actions)"] --> Registre["Registre<br/>(Harbor)"]
        Registre --> Miroirs["Miroirs<br/>(Pkgs)"]
    end
    Registre --> Prod["Production<br/>(Kubernetes)"]

Chapitres

Chapitre Sujet
Fondamentaux Spec OCI, layers, manifests, tags vs digests, signing, réplication
Comparaison des solutions Harbor vs Gitea Packages vs GitLab CR vs Docker Distribution — ADR
Architecture de référence Composants Harbor, projet, robot accounts, sizing
Installation et configuration Déploiement Harbor Helm/Podman, TLS, scanner, réplication
Integration CI/CD push, imagePullSecrets, signing, admission control
Confidentialite Classification Confidentiel, RBAC projets, audit, immutabilite
Bonnes pratiques Garbage collection, retention, DR, migration, troubleshooting