Réseaux, DNS et publication de ports

Comprendre le mécanisme

Le réseau d’un conteneur est distinct du contexte réseau de l’application hôte. Dans un conteneur, localhost désigne normalement ce conteneur, pas un autre service. Sur un réseau utilisateur approprié, les services peuvent se joindre par leurs noms. Publier un port associe une écoute hôte à une écoute de conteneur ; EXPOSE documente une intention dans l’image mais ne crée pas à lui seul cette publication.

Raisonner et vérifier

Ne publiez une base sur l’hôte que si un besoin explicite le justifie et contrôlez l’interface d’écoute. Une communication interne entre services n’exige pas nécessairement une ouverture publique. Vérifiez les chemins réels : navigateur vers reverse proxy, proxy vers application, application vers base. Un test depuis l’hôte ne démontre pas toute la résolution DNS interne.

EXPOSE est une indication de l’image

EXPOSE documente un port attendu par le service ; cette instruction ne publie pas automatiquement ce port sur les interfaces de l’hôte. La publication demande une configuration de lancement distincte. Lors d’une revue, séparez ce que l’image décrit de ce que l’instance expose réellement. Une ligne présente dans le Dockerfile ne prouve donc ni accessibilité depuis Internet ni isolement complet du service.

L’adresse de binding fixe une portée

Publier un port avec une adresse hôte explicite choisit une portée d’écoute selon le contexte. Une liaison à 127.0.0.1 n’a pas le même périmètre qu’une écoute générale. Vérifiez les règles du moteur et de l’hôte réellement utilisés. Le test doit provenir d’un point de réseau pertinent : une connexion locale réussie ne prouve pas l’accès depuis l’extérieur, et l’inverse ne doit pas être supposé.

Localhost appartient au contexte courant

Dans le modèle réseau habituel du conteneur, localhost désigne son propre contexte de boucle locale. Il ne signifie pas automatiquement le conteneur voisin ni le serveur de base. Pour joindre une dépendance, utilisez le nom et le réseau prévus par le déploiement. Exécutez le diagnostic depuis le conteneur applicatif afin d’exercer sa résolution et sa connectivité, pas seulement celles du poste hôte.

Résoudre les services par leur contrat

Un réseau Compose peut fournir une résolution par nom de service. Ce nom permet d’éviter de traiter une adresse d’instance éphémère comme une identité fixe éternelle. La présence du nom ne prouve pas encore la disponibilité métier de la dépendance. Testez résolution, connexion et requête utile séparément pour localiser une panne sans attribuer à tout échec SQL une cause de mot de passe.

Vérifier la frontière effectivement exposée

Les ports publiés, interfaces et règles de pare-feu participent à l’accès réel. Une étiquette private dans un document ne bloque pas une publication ouverte. Inventoriez les services qui ont besoin d’une entrée externe et ceux qui peuvent rester sur un réseau interne. Le contrôle doit observer le chemin déployé ; un fichier de configuration seul ne démontre pas que toutes ses règles sont appliquées.

TLS se termine quelque part

Une terminaison TLS au proxy protège le canal jusqu’à cette frontière. Elle ne chiffre pas automatiquement la connexion interne vers l’application. Décrivez chaque saut et les hypothèses de confiance correspondantes. La configuration du proxy doit aussi maîtriser les champs de contexte transmis. Le schéma annoncé par un client non fiable ne doit pas décider librement de la sécurité perçue du parcours.

Communiquer sans publication hôte

Deux services connectés à un réseau prévu peuvent communiquer sans que chaque port soit publié vers l’hôte ou Internet. Une base réservée à l’application n’a donc pas nécessairement besoin d’une exposition externe. Cela ne supprime pas l’authentification et les permissions SQL. Limitez les voies d’accès utiles, puis testez le parcours réellement utilisé par le consommateur plutôt qu’ouvrir une interface supplémentaire uniquement pour faciliter un diagnostic.

L’absence de port public ne bloque pas les sorties

Une politique d’entrée et une politique de sortie répondent à des directions différentes. Un conteneur sans port publié peut encore appeler des services distants selon sa configuration. Pour un client HTTP piloté par des données reçues, limitez les destinations et les budgets. La confidentialité d’une dépendance interne ne doit pas être supposée à partir de la seule absence d’une publication de port sur l’application.

DNS et redirections peuvent changer la destination

Un nom initialement admis peut conduire à d’autres adresses, et une redirection peut choisir un autre hôte. Le client doit suivre un contrat de sortie maîtrisé sur tout le parcours. Évitez de considérer HTTPS comme une autorisation universelle de destination. Les tests doivent simuler un partenaire qui redirige hors du périmètre et vérifier que le service ne contacte pas librement une ressource interne.

Observer depuis les bons points

Un diagnostic réseau doit préciser d’où la demande est émise et quel saut il mesure. L’hôte, un conteneur applicatif et un navigateur distant peuvent avoir des résolutions et règles différentes. Conservez les versions, noms et erreurs expurgées. Cette chronologie évite les corrections aveugles, comme publier la base mondialement alors que le défaut concernait seulement le nom de service utilisé dans le conteneur.

Atelier guidé : lire, expliquer et vérifier le code

services:
  api:
    image: example/lab-api:1
    ports:
      - "127.0.0.1:8080:80"

La publication montrée utilise 127.0.0.1 comme adresse hôte et 8080 comme port hôte, vers le port 80 du conteneur. Elle demande donc une portée locale dans ce contexte, pas une écoute générale du port 80 de l’hôte. Le registre d’image n’est pas l’interface de publication et ne décide pas de cette adresse.

Vérifiez le mapping dans un laboratoire depuis l’hôte puis depuis un autre point réseau prévu pour le test. Comparez avec une communication entre services qui utilise le réseau interne plutôt que le port publié. Documentez les résultats sans les extrapoler à toute topologie. Une configuration peut être correcte pour un proxy local et insuffisante ou trop large pour un autre mode de déploiement.