Docker DCT

Fiche express
Type	Docker Trusted Registry (DTR) — registre d'images d'entreprise
Éditeur historique	Docker Inc., puis Mirantis (voir Docker EE)
Statut	Produit historique — écosystème largement réorganisé depuis (à vérifier selon l'offre actuelle du fournisseur)
Outil d'install.	Mirantis Launchpad
Voir aussi	Docker trust · Docker EE · Docker registry

Attention au nom de cette page : malgré ce que son titre pourrait laisser penser, elle ne traite pas de la signature d'images (« Content Trust », voir Docker trust) mais du Docker Trusted Registry (DTR), le registre d'images d'entreprise qui accompagnait l'offre Docker Enterprise Edition. Les deux sujets sont liés — un DTR peut exiger des images signées — mais répondent à des besoins différents : DTR est un produit de registre packagé et supporté, quand Content Trust est un mécanisme de signature disponible avec le client Docker standard.

Présentation

DTR ajoute, par rapport à un registre auto-hébergé minimal (voir Docker registry), les fonctions attendues d'un registre d'entreprise :

• interface web d'administration ;
• haute disponibilité à travers plusieurs nœuds de registre ;
• mise en cache géographique des images au plus près des utilisateurs ;
• contrôle d'accès basé sur les rôles (RBAC) ;
• scanner de vulnérabilités intégré pour les images stockées.

DTR se déploie en complément de l'Universal Control Plane (UCP), la brique de gestion de cluster de l'offre Docker Enterprise / Mirantis — voir Docker EE pour le contexte produit complet.

Installation

Génération des certificats

Autorité de certification locale, puis certificat de service DTR :

openssl genrsa -out ca.key 4096
openssl req -x509 -new -nodes -key ca.key -sha256 -days 1024 \
  -subj "/OU=dtr/CN=DTR CA" -out ca.crt

openssl genrsa -out dtr.key 2048
openssl req -new -sha256 -key dtr.key -subj "/OU=dtr/CN=system:dtr" -out dtr.csr

keyUsage = critical, digitalSignature, keyEncipherment
basicConstraints = critical, CA:FALSE
extendedKeyUsage = serverAuth, clientAuth
subjectAltName = DNS:<nom DNS public du serveur DTR>,IP:<IP privée du serveur DTR>,IP:127.0.0.1

openssl x509 -req -in dtr.csr -CA ca.crt -CAkey ca.key -CAcreateserial \
  -out dtr.crt -days 365 -sha256 -extfile extfile.cnf

Déclaration du cluster (Mirantis Launchpad)

L'installation d'UCP et DTR est pilotée par un manifeste déclaratif consommé par l'outil launchpad :

apiVersion: launchpad.mirantis.com/v1beta3
kind: DockerEnterprise
metadata:
  name: launchpad-ucp
spec:
  ucp:
    version: 3.5.3          # à vérifier : figer sur la version réellement supportée
    installFlags:
    - --admin-username=admin
    - --admin-password=<mot de passe robuste, hors dépôt de code>
    - --default-node-orchestrator=kubernetes
    - --force-minimums
  dtr:
    version: 2.8.2           # à vérifier
    installFlags:
    - --ucp-insecure-tls
    - |-
      --dtr-cert "<contenu de dtr.crt>"
    - |-
      --dtr-key "<contenu de dtr.key>"
    - |-
      --dtr-ca "<contenu de ca.crt>"
  hosts:
  - address: <IP privée manager>
    privateInterface: ens5
    role: manager
    ssh:
      user: <utilisateur admin>
      keyPath: ~/launchpad_id
  - address: <IP privée worker>
    privateInterface: ens5
    role: worker
    ssh:
      user: <utilisateur admin>
      keyPath: ~/launchpad_id
  - address: <IP privée dtr>
    privateInterface: ens5
    role: dtr
    ssh:
      user: <utilisateur admin>
      keyPath: ~/launchpad_id

./launchpad apply -c ./cluster.yaml

Le mot de passe administrateur et les clés privées (certificats, clé SSH) ne doivent jamais être committés en clair dans un dépôt de code ; le manifeste ci-dessus est un modèle à compléter via un mécanisme de secrets (variables d'environnement, coffre-fort de secrets, injection CI/CD).