infra / docker

Registry privé

Leçon 131 exercice

Explication

Ce que vous allez apprendre

Comprendre pourquoi une entreprise ne peut pas toujours publier ses images sur Docker Hub
Héberger un registre privé minimal avec l'image officielle registry:2
Sécuriser un registre en production avec TLS et une authentification
Choisir entre un registre auto-hébergé et un registre managé (ECR, GHCR, GitLab)
Comprendre pourquoi certains registres managés imposent une réauthentification régulière

Dans quel contexte ?

Une entreprise développe une application propriétaire et refuse catégoriquement de publier ses images sur Docker Hub, même en mode privé payant, pour des raisons de conformité interne. Elle héberge son propre registre avec l'image registry:2, protégé par TLS et une authentification par mot de passe, directement sur son infrastructure interne. Toute l'équipe pousse et récupère ses images via ce registre, jamais exposé à Internet.

Pourquoi ne pas toujours utiliser Docker Hub

Docker Hub, le registre public par défaut, convient très bien pour des images open source. Mais pour des images internes à une entreprise (contenant du code propriétaire, par exemple), les publier sur un registre public n'est en général pas envisageable. Il faut alors soit héberger son propre registre, soit utiliser un registre privé géré par un fournisseur.

Approche	Avantage	Inconvénient
Registre auto-hébergé (`registry:2`)	Contrôle total	Maintenance à charge de l'équipe
Registre managé (ECR, GHCR, GitLab)	Aucune maintenance d'infra	Dépendance à un service tiers

Piège fréquent

Un registre minimal lancé sans configuration supplémentaire n'a ni chiffrement (HTTPS), ni authentification : n'importe qui ayant accès réseau au serveur peut alors récupérer — ou pire, publier — des images. En production, TLS et authentification ne sont jamais optionnels.

Un registre, c'est juste un serveur avec une API

Un point important à comprendre : un registre Docker n'est pas une notion magique, c'est un serveur applicatif qui expose une API HTTP standardisée permettant de pousser, lister et récupérer des images. L'image officielle registry:2 implémente exactement cette API et peut tourner elle-même... dans un conteneur Docker. C'est pour cela qu'on peut interroger son contenu avec de simples requêtes HTTP (/v2/_catalog), sans outil spécial.

Ne jamais laisser un registre ouvert sans protection

Auto-hébergé ou managé : un vrai choix d'architecture

Héberger son propre registre donne un contrôle total mais impose de le maintenir (mises à jour, sauvegardes, sécurité). Les registres managés (Docker Hub, GitHub Container Registry, AWS ECR, GitLab Container Registry) déchargent cette maintenance, au prix d'une dépendance à un service tiers — souvent le choix par défaut pour la majorité des équipes qui n'ont pas de besoin spécifique d'auto-hébergement.

Piège fréquent

Sur certains registres managés (notamment AWS ECR), les identifiants de connexion sont temporaires et expirent : un pipeline d'intégration continue doit donc se réauthentifier régulièrement, pas une seule fois pour toutes.

Commandes & code

Registry privé

# Lancer un registre Docker privé minimal (auto-hébergé)
docker run -d -p 5000:5000 --restart unless-stopped \
  -v registry_data:/var/lib/registry \
  --name registry registry:2

# Pousser une image vers ce registre local
docker tag mon-api:1.0 localhost:5000/mon-api:1.0
docker push localhost:5000/mon-api:1.0
docker pull localhost:5000/mon-api:1.0

# Lister le contenu d'un registre via son API HTTP
curl http://localhost:5000/v2/_catalog
curl http://localhost:5000/v2/mon-api/tags/list

# Registre sécurisé en HTTPS + authentification (production)
# docker-compose.yml
services:
  registry:
    image: registry:2
    ports:
      - "5000:5000"
    environment:
      REGISTRY_AUTH: htpasswd
      REGISTRY_AUTH_HTPASSWD_REALM: Registry
      REGISTRY_AUTH_HTPASSWD_PATH: /auth/htpasswd
      REGISTRY_HTTP_TLS_CERTIFICATE: /certs/domain.crt
      REGISTRY_HTTP_TLS_KEY: /certs/domain.key
    volumes:
      - ./auth:/auth
      - ./certs:/certs
      - registry_data:/var/lib/registry

volumes:
  registry_data:

# Créer les identifiants d'accès (htpasswd)
docker run --rm --entrypoint htpasswd httpd:2.4 -Bbn deploy motdepasse_fort > auth/htpasswd

docker login registry.exemple.com          # authentification avant push/pull

# --- Registres managés (alternative courante à l'auto-hébergement) ---
# Docker Hub, GitHub Container Registry (ghcr.io), AWS ECR, GitLab Container Registry
docker login ghcr.io -u mon_user
docker tag mon-api:1.0 ghcr.io/mon-org/mon-api:1.0
docker push ghcr.io/mon-org/mon-api:1.0

# Authentification à AWS ECR (le token expire, à renouveler régulièrement en CI)
aws ecr get-login-password --region eu-west-1 | \
  docker login --username AWS --password-stdin 123456789.dkr.ecr.eu-west-1.amazonaws.com

# Politique de rétention : garder les registres légers (éviter d'accumuler indéfiniment des tags)
# La plupart des registres managés proposent des règles de purge automatique par âge/nombre de tags

Résumé

L'image officielle registry:2 suffit pour un registre privé auto-hébergé minimal.
En production, chiffrer en TLS et authentifier (htpasswd ou solution managée) sont non négociables.
Les registres managés (ECR, GHCR, GitLab) évitent la maintenance d'infrastructure au prix d'une dépendance externe.

Exercices pratiques

1 disponible

Mission : sécuriser un registre privé laissé grand ouvert

Objectif : Identifier une faille de configuration d'un registre auto-hébergé et le sécuriser correctement.

Contexte

Un test d'intrusion découvre un registre Docker interne (registry:2) accessible sur le réseau de l'entreprise sans TLS ni authentification : n'importe qui sur le réseau peut consulter et même publier des images.

Résoudre l’exercice →