Meshnet, Docker e l’autorizzazione nel mezzo

Due URL possono sembrare identici dal browser di un peer e significare cose molto diverse per il firewall. Uno punta a un servizio in ascolto sull’host stesso. L’altro punta a un indirizzo dell’host la cui porta è pubblicata in una rete di container, dove un passaggio di traduzione consegna la connessione a un altro IP. In una mesh peer-to-peer che controlla l’accesso alla rete locale con un’autorizzazione per peer, quella differenza è tutta la revisione.

L’autorizzazione riguarda l’endpoint dell’host, la traduzione riguarda Docker e l’accesso riguarda l’applicazione. Tre decisioni, tre punti da guardare.

Seguite la destinazione dopo la pubblicazione

Prendete un host Linux Docker che pubblica la porta 80 di un container sulla porta 8080 dell’host. Un peer si connette all’indirizzo mesh dell’host sulla 8080, l’host accetta la connessione e una traduzione di destinazione la riscrive verso l’indirizzo di bridge del container, di solito qualcosa come 172.17.0.2 sulla porta 80.

Quando una regola ispeziona quel flusso, la destinazione interessante è il container, non l’host. Una politica che ragiona solo su «un servizio su questa macchina» ragiona sull’oggetto sbagliato. La richiesta è arrivata sull’host, ma viene consegnata altrove.

Per questo la documentazione della mesh elenca i container Docker tra le risorse che l’autorizzazione di rete locale governa su Linux. L’autorizzazione non è sinonimo di una voce ordinaria in una lista di consentiti VPN, e i due controlli non si sostituiscono. Uno decide se un peer può raggiungere le risorse locali; l’altro decide quali destinazioni trasporta una rotta in tunnel.

Decidete quanta accesso locale concede un’autorizzazione

Concedere a un peer l’accesso alla rete locale non è una decisione su un singolo container. Può esporre altri servizi pubblicati sullo stesso host e può arrivare più lontano a seconda di come l’host inoltra. Esaminate l’ambito effettivo prima di premere l’interruttore per un pannello.

Poi guardate dove Docker pubblica la porta. Una pubblicazione su 0.0.0.0 crea un listener su ogni indirizzo dell’host, il che può aggiungere una voce LAN ordinaria accanto a quella della mesh. Se il requisito è solo la mesh, legate la pubblicazione all’indirizzo o all’interfaccia precisa che intendete, e trattate il binding più ampio come un rilievo separato e non come una comodità.

Mantenete la politica di inoltro dell’host e l’autenticazione propria dell’applicazione abbastanza strette per il servizio. Un URL dall’aria privata non è un controllo di accesso, e un container che si fida di ogni origine sulla propria rete bridge non è protetto dal fatto che il peer della mesh sia stato approvato. L’autenticazione dell’applicazione è la terza decisione, ed è l’unica che sa chi è l’utente. Un’autorizzazione a livello di host non può fornire quella conoscenza.

Provate l’autorizzazione, non solo l’URL

Dal peer approvato, aprite il servizio esatto e confermate che funziona. Poi provate una destinazione che dovrebbe restare negata e confermate che non funziona. Provare solo il percorso felice vi dice che l’autorizzazione è stata concessa; non vi dice che il confine è dove pensate.

Confrontate separatamente un servizio nativo dell’host. Se un database ascolta sull’host e un pannello gira in un container, seguono percorsi diversi attraverso la stessa autorizzazione e potrebbero non essere governati allo stesso modo dalla politica di inoltro dell’host. Annotate quale è quale prima di scrivere la nota di revisione.

Non svuotate le tabelle di Docker né le regole del client della mesh per «reimpostare» l’accesso. Entrambi i prodotti installano la propria integrazione di policy, e cancellarla produce un host che sembra funzionare mentre aggira i controlli che vi è stato chiesto di valutare. Se una regola sembra sbagliata, leggetela e cambiate solo quella regola. Se non riuscite a spiegare cosa fa una regola, quello è il rilievo, non un motivo per cancellarla.

Scrivete il rilievo nei termini del sistema stesso

Conta la distinzione che il prodotto applica davvero, non quella del modello di revisione: autorizzazione a raggiungere un endpoint dell’host, autorizzazione a raggiungere risorse private instradate e autorizzazione a usare l’applicazione. Pubblicare una porta lascia quelle tre decisioni esattamente dove erano, e un revisore che le tratta come una sola approverà l’ambito sbagliato.

Indicate l’indirizzo dell’host, la porta pubblicata, la destinazione del container e l’autorizzazione del peer nella stessa frase. Quella frase è verificabile da qualcun altro, ed è ciò che la rende un rilievo e non un’opinione.