Per què el mode privilegiat és més ampli del que necessita una VPN

El contenidor no volia obrir el seu túnel, així que es va afegir la marca privilegiada i ara funciona. Aquesta seqüència només va establir que faltava com a mínim un permís, i no diu res sobre quin. El mode privilegiat atorga un conjunt de capacitats i accés a dispositius molt més ampli del que necessita una interfície de túnel.

Què canvia realment la marca

Un contenidor privilegiat rep capacitats àmplies i accés als dispositius de l’amfitrió, cosa que és una concessió molt més gran del que requereix el camí de xarxa. El conjunt exacte el documenta l’entorn d’execució i no el fixa la tradició, i la documentació de Docker sobre l’execució de contenidors descriu les opcions de privilegi disponibles. Llegir-la un cop n’hi ha prou per veure que el túnel és una part petita del total.

Dos requisits més estrets cobreixen la majoria de contenidors VPN. Configurar una interfície necessita la capacitat d’administració de xarxa, i obrir el dispositiu de túnel necessita accés a aquest node de dispositiu concret. Són concessions separades, i subministrar-les totes dues encara és més estret que l’opció general. La resta del conjunt privilegiat no té res a veure amb el túnel. Existeix per a càrregues de treball que realment necessiten accés a nivell d’amfitrió, i un contenidor VPN normalment no és una d’elles.

Feu correspondre cada error amb un prerequisit

El missatge d’error us diu quin prerequisit falta si el llegiu abans de suprimir-lo. Un missatge sobre un node de dispositiu anomena el dispositiu, un missatge sobre una operació no permesa anomena una capacitat, i un missatge sobre un mòdul o un sysctl anomena suport del nucli. Cadascun té una solució diferent, i només un d’ells és una capacitat.

Un fitxer de configuració que falta continua faltant després de concedir tots els permisos, i per això el mode privilegiat de vegades no canvia res de res. El contenidor arrenca, el túnel continua fallant, i l’error real mai no era sobre permisos. El suport del nucli és el tercer cas i el més fàcil de malinterpretar. Un mòdul que no està carregat a l’amfitrió no es pot carregar des de dins d’un contenidor no privilegiat, i concedir més capacitats dins del contenidor no canvia l’estat de l’amfitrió.

Comproveu el requisit, no el símptoma

Comenceu per la invocació mínima que documenta la imatge, executeu-la i conserveu el text exacte de la fallada. Després afegiu una concessió alhora i anoteu quina addició va canviar el resultat.

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 contenidor que veu el dispositiu i té la capacitat però tot i així falla us diu que el problema és en un altre lloc. És un resultat útil, i el mode privilegiat l’hauria amagat.

Comproveu també els permisos del dispositiu a l’amfitrió, perquè un node de dispositiu concedit correctament amb la propietat de grup equivocada produeix el mateix error que una concessió que falta.

Anoteu la concessió més estreta que funcioni

Anoteu cada dispositiu i capacitat que necessita el desplegament, amb l’error que els va justificar. Aquest registre és el que permet a la persona següent treure alguna cosa amb seguretat, i és el que demanarà un auditor quan es notifiqui un contenidor com a privilegiat.

Reviseu també el context del voltant, perquè la xarxa de l’amfitrió, els muntatges de l’amfitrió i les opcions de l’entorn d’execució poden ampliar cadascun l’impacte d’una concessió. Una invocació aïllada de laboratori que ho combina tot no és una configuració de producció, per bé que hagi funcionat. Proveu l’aplicació, el seu comportament en DNS i una fallada de túnel abans de donar el desplegament per acabat. El permís per crear una interfície no és una política de sortida, i un contenidor que pot tunelitzar perfectament encara encamina tot el que envia l’aplicació.