Pourquoi le mode privilégié est plus large que ce dont un VPN a besoin

Le conteneur ne voulait pas ouvrir son tunnel, alors le drapeau privilégié a été ajouté, et maintenant cela fonctionne. Cette séquence a seulement établi qu’au moins une permission manquait, et elle ne dit rien sur laquelle. Le mode privilégié accorde un ensemble de capacités et un accès aux périphériques bien plus large que ce dont une interface de tunnel a besoin.

Ce que le drapeau change réellement

Un conteneur privilégié reçoit de larges capacités et l’accès aux périphériques de l’hôte, ce qui est une autorisation bien plus grande que ne l’exige le chemin réseau. L’ensemble exact est documenté par l’environnement d’exécution plutôt que fixé par la tradition, et la documentation Docker sur l’exécution des conteneurs décrit les options de privilège disponibles. Une seule lecture suffit pour voir que le tunnel est une petite partie du total.

Deux exigences plus étroites couvrent la plupart des conteneurs VPN. Configurer une interface nécessite la capacité d’administration du réseau, et ouvrir le périphérique de tunnel nécessite l’accès à ce nœud de périphérique précis. Ce sont des autorisations distinctes, et même les deux ensemble restent plus étroites que l’option globale. Le reste de l’ensemble privilégié n’a rien à voir avec le tunnel. Il existe pour des charges de travail qui ont réellement besoin d’un accès au niveau de l’hôte, et un conteneur VPN n’en fait généralement pas partie.

Associez chaque erreur à un prérequis

Le message d’erreur vous dit quel prérequis manque si vous le lisez avant de le supprimer. Un message sur un nœud de périphérique nomme le périphérique, un message sur une opération non autorisée nomme une capacité, et un message sur un module ou un sysctl nomme le support du noyau. Chacun a une correction différente, et un seul d’entre eux est une capacité.

Un fichier de configuration manquant reste manquant après l’octroi de toutes les capacités, ce qui explique pourquoi le mode privilégié ne change parfois absolument rien. Le conteneur démarre, le tunnel échoue toujours, et la véritable erreur n’a jamais porté sur les permissions. Le support du noyau est le troisième cas et le plus facile à mal lire. Un module qui n’est pas chargé sur l’hôte ne peut pas être chargé depuis l’intérieur d’un conteneur non privilégié, et accorder plus de capacités à l’intérieur du conteneur ne change pas l’état de l’hôte.

Vérifiez l’exigence, pas le symptôme

Partez de l’invocation minimale que l’image documente, exécutez-la et conservez le texte exact de l’échec. Ajoutez ensuite une autorisation à la fois et notez quel ajout a changé le résultat.

ls -l /dev/net/tun
docker run --rm --cap-add NET_ADMIN --device /dev/net/tun image:tag
ip -br link show type tun

Un conteneur qui voit le périphérique et détient la capacité mais échoue quand même vous dit que le problème est ailleurs. C’est un résultat utile, et le mode privilégié l’aurait masqué.

Vérifiez aussi les permissions du périphérique sur l’hôte, car un nœud de périphérique correctement accordé avec une mauvaise appartenance de groupe produit la même erreur qu’une autorisation manquante.

Consignez l’autorisation la plus étroite qui fonctionne

Notez chaque périphérique et capacité dont le déploiement a besoin, avec l’erreur qui l’a justifié. Ce relevé est ce qui permet à la personne suivante de retirer quelque chose en sécurité, et c’est ce qu’un auditeur demandera quand un conteneur sera signalé comme privilégié.

Examinez aussi le contexte environnant, car le réseau de l’hôte, les montages de l’hôte et les options d’exécution peuvent chacun élargir l’impact d’une autorisation. Une invocation isolée de laboratoire qui les combine toutes n’est pas une configuration de production, aussi bien ait-elle fonctionné. Testez l’application, son comportement DNS et un échec de tunnel avant de déclarer le déploiement terminé. L’autorisation de créer une interface n’est pas une politique de sortie, et un conteneur qui sait parfaitement tunneler achemine encore tout ce que l’application envoie.