Docker registry

Fiche express
Type	Registre d'images Docker auto-hébergé (image officielle registry)
Référence	https://docs.docker.com/registry/
Port usuel	443 (HTTPS) ou 5000 (historique)
Authentification	Aucune, ou htpasswd
Voir aussi	Docker daemon.json · Docker trust · TLS

L'image officielle registry permet d'héberger un registre d'images Docker privé, sans dépendre d'un service tiers. Elle convient à un usage interne (miroir, images maison, environnement isolé) ; pour des besoins avancés (contrôle d'accès par rôle, scan de vulnérabilités, haute disponibilité), voir les registres d'entreprise évoqués dans Docker DCT.

Préparation

mkdir -p /registry /certs /auth

Sans authentification

Génération du certificat

Un certificat auto-signé suffit pour un usage interne, à condition de le distribuer aux clients (ou de déclarer le registre comme non sécurisé, voir Docker daemon.json) :

openssl req -newkey rsa:4096 -nodes -sha256 \
  -keyout /certs/registry.example.local.key \
  -addext "subjectAltName = DNS:registry.example.local" \
  -x509 -days 365 -out /certs/registry.example.local.crt

Déclaration côté client Docker

Si le certificat n'est pas ajouté au magasin de confiance du système, il faut déclarer le registre comme non sécurisé dans /etc/docker/daemon.json :

{
  "insecure-registries": ["registry.example.gitlab:5050", "registry.example.local:443"]
}

Lancement du registre

docker run -d --restart=always --name registry \
  -v /certs:/certs \
  -v /registry/:/registry/ \
  -e REGISTRY_HTTP_ADDR=0.0.0.0:443 \
  -e REGISTRY_HTTP_TLS_CERTIFICATE=/certs/registry.example.local.crt \
  -e REGISTRY_HTTP_TLS_KEY=/certs/registry.example.local.key \
  -e REGISTRY_STORAGE_FILESYSTEM_ROOTDIRECTORY=/registry/ \
  -p 443:443 registry:2

Vérification

curl -sSL --insecure https://<IP du conteneur>:443/v2/_catalog
curl -sSL --insecure https://registry.example.local/v2/_catalog

Pousser une image

docker tag mon-image:latest registry.example.local/mon-image:v1.0.0
docker push registry.example.local/mon-image:v1.0.0

Avec authentification (htpasswd)

Un registre exposé au-delà d'une machine locale devrait toujours être protégé par une authentification a minima. La variante la plus simple s'appuie sur un fichier htpasswd :

docker run -d -p 443:443 --restart=always --name registry \
  -v /certs:/certs \
  -v /auth/:/auth \
  -v /registry/:/registry/ \
  -e REGISTRY_AUTH=htpasswd \
  -e REGISTRY_AUTH_HTPASSWD_REALM="Registry Realm" \
  -e REGISTRY_AUTH_HTPASSWD_PATH=/auth/htpasswd \
  -e REGISTRY_HTTP_ADDR=0.0.0.0:443 \
  -e REGISTRY_HTTP_TLS_CERTIFICATE=/certs/registry.example.local.crt \
  -e REGISTRY_HTTP_TLS_KEY=/certs/registry.example.local.key \
  -e REGISTRY_STORAGE_FILESYSTEM_ROOTDIRECTORY=/registry/ \
  registry:2

Génération du fichier d'authentification (le mot de passe est fourni de façon interactive ou via une variable, jamais en clair dans l'historique du shell en production) :

docker run --entrypoint htpasswd httpd:2 -Bbn <utilisateur> <mot_de_passe> > auth/htpasswd

Utilisation :

docker login registry.example.local

docker tag mon-image:latest registry.example.local/mon-image:v1.0.0
docker push registry.example.local/mon-image:v1.0.0

Usage général (registre déjà en place)

# Connexion
docker login <nom_dns_public_du_registre>

# Registre avec certificat auto-signé : le déclarer non sécurisé
# dans /etc/docker/daemon.json, puis relancer le démon
systemctl restart docker

# Cycle complet pull / tag / push / nettoyage
docker pull ubuntu
docker tag ubuntu <nom_dns_public_du_registre>/ubuntu
docker push <nom_dns_public_du_registre>/ubuntu
docker image rm <nom_dns_public_du_registre>/ubuntu
docker image rm ubuntu
docker pull <nom_dns_public_du_registre>/ubuntu

Sécurité

• Un registre sans authentification ne devrait jamais être exposé au-delà d'un réseau strictement de confiance : n'importe qui peut y pousser ou en tirer des images.
• Le mode insecure-registries désactive la vérification TLS : à réserver au développement ou à un environnement fermé, jamais à un registre accessible depuis un réseau non maîtrisé.
• Pour garantir l'intégrité des images distribuées (et pas seulement le transport), voir la signature d'images avec Docker Content Trust.