Perché la modalità privilegiata è più ampia di quanto serva a una VPN

Il container non apriva il suo tunnel, così è stato aggiunto il flag privilegiato, e ora funziona. Quella sequenza ha stabilito solo che mancava almeno un permesso, e non dice nulla su quale. La modalità privilegiata concede un insieme di capacità e un accesso ai dispositivi molto più ampio di quanto serva a un’interfaccia di tunnel.

Cosa cambia davvero il flag

Un container privilegiato riceve capacità ampie e accesso ai dispositivi dell’host, che è una concessione molto più grande di quanto richieda il percorso di rete. L’insieme esatto è documentato dall’ambiente di esecuzione e non fissato dalla tradizione, e la documentazione Docker sull’esecuzione dei container descrive le opzioni di privilegio disponibili. Leggerla una volta basta per vedere che il tunnel è una piccola parte del totale.

Due requisiti più stretti coprono la maggior parte dei container VPN. Configurare un’interfaccia richiede la capacità di amministrazione della rete, e aprire il dispositivo del tunnel richiede l’accesso a quel nodo di dispositivo preciso. Sono concessioni separate, e anche insieme restano più strette dell’opzione generale. Il resto dell’insieme privilegiato non ha nulla a che fare con il tunnel. Esiste per carichi di lavoro che hanno davvero bisogno di accesso a livello di host, e un container VPN di solito non è uno di questi.

Abbinate ogni errore a un prerequisito

Il messaggio di errore vi dice quale prerequisito manca se lo leggete prima di sopprimerlo. Un messaggio su un nodo di dispositivo nomina il dispositivo, un messaggio su un’operazione non consentita nomina una capacità, e un messaggio su un modulo o un sysctl nomina il supporto del kernel. Ognuno ha una correzione diversa, e solo uno di essi è una capacità.

Un file di configurazione mancante resta mancante dopo aver concesso tutte le capacità, ed è per questo che la modalità privilegiata a volte non cambia assolutamente nulla. Il container parte, il tunnel fallisce comunque, e l’errore reale non ha mai riguardato i permessi. Il supporto del kernel è il terzo caso e il più facile da leggere male. Un modulo non caricato sull’host non può essere caricato dall’interno di un container non privilegiato, e concedere più capacità dentro il container non cambia lo stato dell’host.

Verificate il requisito, non il sintomo

Partite dall’invocazione minima che l’immagine documenta, eseguitela e conservate il testo esatto dell’errore. Poi aggiungete una concessione alla volta e annotate quale aggiunta ha cambiato il risultato.

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 container che vede il dispositivo e possiede la capacità ma fallisce comunque vi sta dicendo che il problema è altrove. È un risultato utile, e la modalità privilegiata lo avrebbe nascosto.

Controllate anche i permessi del dispositivo sull’host, perché un nodo di dispositivo concesso correttamente con la proprietà di gruppo sbagliata produce lo stesso errore di una concessione mancante.

Annotate la concessione più stretta che funziona

Annotate ogni dispositivo e capacità di cui ha bisogno la distribuzione, con l’errore che li ha giustificati. È quel registro che permette alla persona successiva di rimuovere qualcosa in sicurezza, ed è quello che un revisore chiederà quando un container sarà segnalato come privilegiato.

Esaminate anche il contesto circostante, perché rete dell’host, mount dell’host e opzioni dell’ambiente di esecuzione possono ciascuna ampliare l’impatto di una concessione. Un’invocazione isolata di laboratorio che le combina tutte non è una configurazione di produzione, per quanto bene abbia funzionato. Provate l’applicazione, il suo comportamento DNS e un errore del tunnel prima di dichiarare la distribuzione completata. L’autorizzazione a creare un’interfaccia non è una politica di uscita, e un container che sa fare tunnel perfettamente instrada comunque tutto ciò che l’applicazione invia.