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 |