Meshnet, Docker et l’autorisation entre les deux

Deux URL peuvent sembler identiques depuis le navigateur d’un pair et signifier des choses très différentes pour le pare-feu. L’une désigne un service qui écoute sur l’hôte lui-même. L’autre désigne une adresse d’hôte dont le port est publié dans un réseau de conteneurs, où une étape de traduction remet la connexion à une autre IP. Dans un maillage pair à pair qui contrôle l’accès au réseau local par une autorisation propre à chaque pair, cette différence fait toute l’analyse.

L’autorisation concerne le point de terminaison de l’hôte, la traduction concerne Docker et la connexion concerne l’application. Trois décisions, trois endroits à examiner.

Suivez la destination après la publication

Prenez un hôte Linux Docker qui publie le port 80 d’un conteneur sur le port 8080 de l’hôte. Un pair se connecte à l’adresse de maillage de l’hôte sur 8080, l’hôte accepte la connexion, et une traduction de destination la réécrit vers l’adresse de pont du conteneur, généralement quelque chose comme 172.17.0.2 sur le port 80.

Au moment où une règle inspecte ce flux, la destination intéressante est le conteneur, pas l’hôte. Une politique qui ne raisonne que sur « un service sur cette machine » raisonne sur le mauvais objet. La requête a atterri sur l’hôte, mais elle est livrée ailleurs.

C’est pourquoi la documentation du maillage classe les conteneurs Docker parmi les ressources que l’autorisation de réseau local régit sous Linux. L’autorisation n’est pas synonyme d’une entrée ordinaire dans une liste d’autorisation VPN, et les deux contrôles ne se substituent pas l’un à l’autre. L’un décide si un pair peut atteindre des ressources locales ; l’autre décide quelles destinations transporte une route tunnelisée.

Décidez quelle quantité d’accès local une autorisation accorde

Accorder à un pair l’accès au réseau local n’est pas une décision portant sur un seul conteneur. Cela peut exposer d’autres services publiés sur le même hôte, et cela peut aller plus loin selon la façon dont l’hôte transfère. Examinez la portée effective avant de basculer l’interrupteur pour un tableau de bord.

Regardez ensuite où Docker publie le port. Une publication sur 0.0.0.0 crée un écouteur sur chaque adresse de l’hôte, ce qui peut ajouter une entrée LAN ordinaire à côté de celle du maillage. Si l’exigence est le maillage seul, liez la publication à l’adresse ou à l’interface précise que vous visez, et traitez la liaison plus large comme une constatation distincte plutôt que comme une commodité.

Gardez la politique de transfert de l’hôte et l’authentification propre à l’application assez étroites pour le service. Une URL d’apparence privée n’est pas un contrôle d’accès, et un conteneur qui fait confiance à toutes les sources de son réseau de pont n’est pas protégé par le fait que le pair du maillage a été approuvé. L’authentification de l’application est la troisième décision, et c’est la seule qui sache qui est l’utilisateur. Une autorisation au niveau de l’hôte ne peut pas fournir cette connaissance.

Testez l’autorisation, pas seulement l’URL

Depuis le pair approuvé, ouvrez le service exact et confirmez qu’il fonctionne. Essayez ensuite une destination qui devrait rester refusée et confirmez qu’elle ne fonctionne pas. Ne tester que le chemin heureux vous dit que l’autorisation a été accordée ; cela ne vous dit pas que la frontière est là où vous croyez.

Comparez séparément un service natif de l’hôte. Si une base de données écoute sur l’hôte et qu’un tableau de bord s’exécute dans un conteneur, ils suivent des chemins différents à travers la même autorisation et peuvent ne pas être régis de la même manière par la politique de transfert de l’hôte. Notez lequel est lequel avant de rédiger la note d’analyse.

Ne videz pas les tables de Docker ni les règles du client de maillage pour « réinitialiser » l’accès. Les deux produits installent leur propre intégration de politique, et la supprimer produit un hôte qui semble fonctionner tout en contournant les contrôles que l’on vous a demandé d’évaluer. Si une règle semble erronée, lisez-la et modifiez cette règle-là. Si vous ne pouvez pas expliquer ce que fait une règle, c’est la constatation, pas une raison de la supprimer.

Rédigez la constatation dans les termes du système lui-même

Ce qui compte est la distinction que le produit applique réellement, pas celle du modèle d’analyse : l’autorisation d’atteindre un point de terminaison de l’hôte, l’autorisation d’atteindre des ressources privées routées et l’autorisation d’utiliser l’application. Publier un port laisse ces trois décisions exactement là où elles étaient, et un analyste qui les traite comme une seule approuvera la mauvaise portée.

Indiquez l’adresse de l’hôte, le port publié, la destination du conteneur et l’autorisation du pair dans la même phrase. Cette phrase est vérifiable par quelqu’un d’autre, et c’est ce qui en fait une constatation plutôt qu’une opinion.