Harbor : gérez votre registry Docker privé comme un pro

Harbor, c'est quoi concrètement et pourquoi ça change la donne

Si vous avez déjà géré des images Docker en équipe, vous savez ce que c'est. Les images qui traînent sur Docker Hub en public, les tags latest qui ne veulent plus rien dire, les accès non contrôlés, les scans de sécurité inexistants… À un moment, ça coince.

Harbor, c'est la réponse à ce chaos. Un registry de conteneurs open source, hébergeable on-premise ou dans votre cloud privé, avec une vraie gestion des droits, de la sécurité et de la rétention d'images. Le projet est sous l'égide de la CNCF (Cloud Native Computing Foundation), le même organisme qui chapeaute Kubernetes et Helm. Ça positionne Harbor clairement dans l'écosystème sérieux.

Franchement, si vous déployez des conteneurs en production et que vous n'avez pas encore de registry privé digne de ce nom, lisez cet article jusqu'au bout.

Pourquoi un registry privé plutôt que Docker Hub

Docker Hub reste pratique pour les images publiques. Mais dès qu'on parle d'images maison, de code propriétaire packagé dans un conteneur, ou simplement de limites de pull rate, l'argument tient moins la route.

Voici ce que Docker Hub ne peut pas vous offrir facilement :

• Contrôle d'accès granulaire : qui peut puller, qui peut pusher, sur quel projet
• Scan de vulnérabilités intégré : savoir si vos images embarquent des CVE critiques avant de les déployer
• Rétention d'images automatisée : purger les vieilles versions sans intervention manuelle
• Réplication entre sites : synchroniser vos registries entre plusieurs datacenters ou régions
• Traçabilité complète : logs d'audit, signatures d'images, chaîne de confiance

En prod on a eu le cas où une équipe pushait allègrement des images de 3 Go sur Docker Hub, sans tag propre, sans politique de rétention. Six mois plus tard, le projet avait 200 images inutilisables et personne ne savait laquelle était stable. Harbor aurait évité ça dès le départ.

L'architecture de Harbor décortiquée

Avant de se lancer dans l'installation, comprendre ce qu'on déploie c'est pas du luxe. Harbor n'est pas un simple serveur de fichiers pour images Docker. C'est une plateforme composite.

Les composants clés

Core : le cerveau de Harbor. Il gère l'API, l'authentification, les politiques, les webhooks. Tout passe par là.

Registry : le composant de stockage réel, basé sur la distribution OCI officielle. C'est lui qui reçoit et sert les couches d'images.

Job Service : le gestionnaire de tâches asynchrones. Réplication, scan, garbage collection — tout ce qui ne doit pas bloquer l'API tourne ici.

Portal : l'interface web en Angular. Fonctionnelle, pas extraordinaire visuellement, mais on s'y retrouve.

Notary : la partie signature d'images (optionnelle mais recommandée en environnement sensible).

Trivy : le scanner de vulnérabilités par défaut depuis Harbor 2.x. Remplace l'ancien Clair, et franchement c'est une bonne chose — Trivy est bien plus maintenu.

Database : PostgreSQL pour la persistance des métadonnées.

Redis : pour le cache et les files de jobs.

Ce que ça donne en pratique

[ Développeur ]
      |
      | docker push/pull
      v
[ Harbor Load Balancer / Nginx ]
      |
   --------
   |      |
[Core] [Registry]
   |      |
   |   [Stockage S3 / NFS / Local]
   |
[Job Service] --> [Trivy] (scan)
              --> [Réplication] (autres registries)

Tous ces composants tournent en conteneurs Docker, orchestrés via Docker Compose (en standalone) ou Helm Chart si vous êtes sur Kubernetes.

Installation de Harbor avec Docker Compose

C'est la méthode la plus directe pour une PME ou un lab. On suppose que vous avez Docker et Docker Compose installés.

Téléchargement et configuration initiale

# Télécharger la dernière release stable
wget https://github.com/goharbor/harbor/releases/download/v2.11.0/harbor-online-installer-v2.11.0.tgz

# Extraire l'archive
tar -xvf harbor-online-installer-v2.11.0.tgz
cd harbor

# Copier le fichier de configuration exemple
cp harbor.yml.tmpl harbor.yml

Éditez harbor.yml pour l'adapter à votre environnement :

# harbor.yml — configuration minimale commentée

# FQDN de votre registry — doit matcher votre certificat SSL
hostname: registry.monentreprise.fr

# Configuration HTTPS (obligatoire en production)
https:
  port: 443
  certificate: /etc/harbor/certs/registry.monentreprise.fr.crt
  private_key: /etc/harbor/certs/registry.monentreprise.fr.key

# Mot de passe admin initial — à changer immédiatement après install
harbor_admin_password: ChangeMe@2024!

# Base de données PostgreSQL interne
database:
  password: PostGresStrongPass!

# Répertoire de stockage des données
data_volume: /data/harbor

# Scanner de vulnérabilités — Trivy activé par défaut
trivy:
  ignore_unfixed: false
  # Scanner même les vulnérabilités sans patch disponible
  security_check: vuln

Un truc souvent oublié : le FQDN doit être résolvable depuis tous vos clients qui vont pusher/puller. Si votre DNS interne ne couvre pas registry.monentreprise.fr, vos builds CI/CD vont planter de façon assez obscure.

Lancement de l'installation

# Le script génère les docker-compose et lance les services
sudo ./install.sh --with-trivy

# Vérifier que tous les conteneurs sont up
docker compose ps

Si tout se passe bien, vous devriez avoir une dizaine de conteneurs en Up dans les deux minutes.

Configurer Harbor pour une utilisation professionnelle

L'installation c'est 20% du travail. Le reste c'est la configuration qui fait que Harbor devient vraiment utile.

Gestion des projets et des droits

Harbor organise les images en projets. Chaque projet peut être public ou privé, avec ses propres membres et rôles.

Les rôles disponibles :

• Guest : lecture seule
• Developer : push/pull
• Maintainer : push/pull + gestion des tags et artefacts
• Project Admin : gestion complète du projet

En pratique, pour une équipe de dev : créez un projet par application ou par équipe, assignez les développeurs en Developer, les leads en Maintainer. L'équipe ops hérite du Project Admin. Simple et lisible.

Intégration LDAP / Active Directory

Si votre PME tourne avec Active Directory, Harbor s'y connecte nativement. Direction Administration > Configuration > Authentification, sélectionnez LDAP et renseignez :

• URL du serveur LDAP (ldaps://ad.monentreprise.fr)
• DN de recherche
• Attribut UID (généralement sAMAccountName sur AD)
• Filtre de groupe si nécessaire

Du coup, plus besoin de gérer des comptes Harbor séparément — vos utilisateurs AD se connectent directement, et vous gérez les droits Harbor comme n'importe quelle ressource de votre SI. Si vous avez déjà centralisé l'authentification avec une solution comme Authentik, Harbor supporte également OIDC — c'est même la configuration recommandée pour une architecture SSO moderne.

Politiques de rétention d'images

C'est là que Harbor brille vraiment par rapport à une solution DIY. Les politiques de rétention permettent de définir des règles automatiques de nettoyage.

Exemple de règle utile :

Projet : backend-api
Règle : conserver les 10 derniers tags pour les branches main et develop
        conserver les tags qui matchent le pattern v*.*.* (semver)
        supprimer tout le reste après 30 jours

Ça s'active dans le projet > Policy > Tag Retention. Harbor prévisualise les images qui seraient supprimées avant d'appliquer la règle — c'est rassurant pour les premières fois.

Scan de vulnérabilités avec Trivy

C'est probablement la feature la plus impactante en environnement pro. Chaque image pushée peut être scannée automatiquement. Vous voyez en un coup d'œil les CVE présentes, leur criticité, et si un correctif est disponible.

Configuration recommandée :

1. Activez le scan automatique à chaque push dans les paramètres du projet
2. Configurez une politique de prévention : bloquer le pull d'images avec des CVE critiques non corrigées
3. Planifiez un re-scan quotidien des images existantes — une image propre aujourd'hui peut avoir des CVE demain si Trivy met à jour sa base

# Déclencher un scan manuellement via l'API Harbor
curl -X POST "https://registry.monentreprise.fr/api/v2.0/projects/backend-api/repositories/mon-app/artifacts/sha256:abc123/scan" \
  -H "Authorization: Basic $(echo -n 'admin:password' | base64)"

Harbor dans un pipeline CI/CD

Un registry privé sans intégration CI/CD, c'est un peu comme un garage sans voiture. L'intérêt c'est d'automatiser.

Exemple avec GitLab CI

# .gitlab-ci.yml — exemple d'intégration Harbor

variables:
  # On définit l'URL du registry Harbor
  HARBOR_REGISTRY: "registry.monentreprise.fr"
  IMAGE_NAME: "$HARBOR_REGISTRY/backend-api/mon-app"

stages:
  - build
  - push
  - deploy

build:
  stage: build
  script:
    # Construction de l'image avec le SHA du commit comme tag
    - docker build -t $IMAGE_NAME:$CI_COMMIT_SHORT_SHA .
    - docker tag $IMAGE_NAME:$CI_COMMIT_SHORT_SHA $IMAGE_NAME:latest

push:
  stage: push
  script:
    # Authentification sur Harbor avec les credentials CI
    - echo "$HARBOR_PASSWORD" | docker login $HARBOR_REGISTRY -u $HARBOR_USER --password-stdin
    - docker push $IMAGE_NAME:$CI_COMMIT_SHORT_SHA
    - docker push $IMAGE_NAME:latest
  only:
    - main
    - develop

Les variables HARBOR_USER et HARBOR_PASSWORD sont à définir dans les secrets GitLab CI. Utilisez un compte robot Harbor (Administration > Robot Accounts) plutôt qu'un compte utilisateur réel — les robot accounts ont des permissions limitées et peuvent être révoqués sans impacter qui que ce soit.

Si vous avez déjà mis en place des pipelines CI/CD dans votre organisation, l'intégration Harbor s'inscrit naturellement dans votre flux existant — ajoutez juste le login registry et adaptez les noms d'images.

Robot Accounts : la bonne pratique

# Création d'un robot account via l'API
curl -X POST "https://registry.monentreprise.fr/api/v2.0/robots" \
  -H "Content-Type: application/json" \
  -H "Authorization: Basic $(echo -n 'admin:password' | base64)" \
  -d '{
    "name": "gitlab-ci-backend",
    "duration": 365,
    "permissions": [
      {
        "kind": "project",
        "namespace": "backend-api",
        "access": [
          {"resource": "repository", "action": "push"},
          {"resource": "repository", "action": "pull"}
        ]
      }
    ]
  }'

Ce robot n'aura accès qu'au projet backend-api, uniquement pour pusher et puller. Rien de plus. Principe du moindre privilège appliqué.

Réplication entre registries

Un use case souvent sous-estimé : répliquer vos images vers d'autres sites ou registries. Harbor le gère nativement.

Cas concrets :

• Multi-datacenter : répliquer les images de Lyon vers Paris pour réduire la latence de pull en production
• Promotion d'environnement : les images validées en staging sont répliquées automatiquement vers le registry de production
• Mirror de Docker Hub : cacher les images publiques fréquemment utilisées pour s'affranchir des rate limits

La configuration se fait dans Administration > Replications. Vous définissez des règles avec source, destination, filtres sur les tags, et déclencheur (push, planifié, ou manuel).

Sécurité avancée : signature d'images avec Cosign

Depuis Harbor 2.5, la signature d'images via Cosign (projet Sigstore) est supportée nativement. L'idée : signer cryptographiquement chaque image au moment du build, et vérifier cette signature avant tout déploiement.

# Signer une image après push
cosign sign --key cosign.key registry.monentreprise.fr/backend-api/mon-app:v1.2.3

# Vérifier une signature avant déploiement
cosign verify --key cosign.pub registry.monentreprise.fr/backend-api/mon-app:v1.2.3

En prod on a eu le cas où un développeur avait pushé une image depuis son poste local, sans passer par le pipeline CI. Avec la vérification Cosign en place au niveau du cluster Kubernetes (via une admission policy), le pod n'aurait tout simplement pas démarré. C'est exactement le type de filet de sécurité qu'on veut.

Cette approche s'inscrit parfaitement dans une stratégie Zero Trust : ne jamais faire confiance par défaut, même à une image interne.

Harbor vs les alternatives

Soyons honnêtes, Harbor n'est pas la seule option.

Harbor gagne clairement sur la colonne features en self-hosted. Si vous êtes déjà full AWS, ECR a du sens. Si vous cherchez la souveraineté et la complétude, Harbor est difficilement battu.

Pour des PME qui veulent garder la maîtrise de leurs images sans dépendre d'un fournisseur externe, c'est le choix naturel — d'autant que ça s'héberge très bien sur une infrastructure Proxmox ou sur un cluster Kubernetes interne.

Maintenance et opérations courantes

Garbage Collection

Les images supprimées via l'UI ne libèrent pas immédiatement l'espace disque. Il faut lancer le Garbage Collector périodiquement.

Administration > Garbage Collection > Planifier. Une fois par semaine en heures creuses, c'est généralement suffisant. Harbor met le registry en mode lecture seule pendant l'opération — à planifier en conséquence.

Sauvegarde Harbor

Les données critiques à sauvegarder :

# 1. La base PostgreSQL
docker exec harbor-db pg_dump -U postgres registry > harbor-backup-$(date +%Y%m%d).sql

# 2. Le répertoire de données (images layers)
rsync -av /data/harbor/ /backup/harbor/

# 3. La configuration
cp harbor/harbor.yml /backup/harbor/config/

Si votre stratégie de sauvegarde globale est déjà structurée, intégrez Harbor dans votre rotation existante. Un guide comme celui sur la sauvegarde 3-2-1 vous donnera le cadre pour organiser ça correctement.

Mise à jour de Harbor

# Arrêter les services
docker compose down

# Sauvegarder avant toute mise à jour (toujours)
# ... voir section sauvegarde ci-dessus

# Télécharger la nouvelle version et relancer l'installation
./install.sh --with-trivy

# Harbor migre automatiquement le schéma de base de données

Les mises à jour mineures (2.x.y vers 2.x.z) sont généralement sans friction. Les mises à jour majeures demandent de lire les release notes — Harbor maintient un guide de migration pour chaque version.

Ce qu'on retient en pratique

Harbor c'est un outil mature, bien documenté, activement maintenu par la communauté CNCF. Pas parfait — l'interface web est fonctionnelle sans être belle, et la configuration initiale demande un peu de temps — mais le rapport fonctionnalités/effort est vraiment bon.

Pour une PME qui containerise ses applications, c'est le registry qu'on recommande sans hésiter. Scan de sécurité, RBAC propre, réplication, intégration CI/CD fluide : tout ce qu'il faut pour ne pas avoir honte de son infra conteneurs.

Mettez votre registry sous contrôle, enfin

Déployer Harbor correctement et l'intégrer dans votre pipeline existant demande un peu de méthode. Si vous voulez accélérer la mise en place ou auditer votre infrastructure conteneurs actuelle, on peut vous accompagner.

Parlez-nous de votre projet