Stork 2.6 unifica il monitoraggio dei lease DHCP e dei zone transfer DNS
Stork 2.6 aggiunge la ricerca dei lease DHCP tra più server, il monitoraggio dei zone transfer di BIND 9, l'accesso tramite OpenID Connect e la gestione del Kea Configuration Backend.
Stork 2.6 amplia lo strumento di gestione open source con il monitoraggio consolidato dei lease del Dynamic Host Configuration Protocol (DHCP) e il monitoraggio dei zone transfer del Domain Name System (DNS). DHCP assegna automaticamente gli indirizzi di rete ai dispositivi, mentre DNS indirizza i nomi Internet verso i sistemi che li servono. ISC descrive la versione 2.6 come una release stabile adatta all'uso in produzione, sebbene segnali anche due problemi noti che gli amministratori dovrebbero esaminare prima del deployment.
La release presenta quattro aggiunte principali: il monitoraggio dei lease su più server Kea DHCP, l'autenticazione tramite OpenID Connect, il monitoraggio dei zone transfer DNS di BIND 9 e il supporto per il Kea Configuration Backend. ISC ha inoltre sostituito una delle principali dipendenze dell'interfaccia utente e introdotto diverse modifiche relative alla sicurezza.
Il monitoraggio consolidato dei lease è pensato per offrire agli amministratori una vista unica delle assegnazioni degli indirizzi in un deployment Kea potenzialmente esteso. Un lease è l'assegnazione temporanea di un indirizzo IP a un dispositivo. Quando la funzionalità è abilitata, gli agent Stork raccolgono le informazioni sui lease dai lease file delle istanze Kea rilevate e le inviano al server centrale. Stork crea quindi un database consultabile che include i lease di tutti i server monitorati. L'implementazione attuale funziona soltanto con il backend memfile di Kea, che archivia i dati dei lease in file.
Gli amministratori possono ordinare, filtrare e cercare i lease raccolti, inclusi i lease DHCPv6 utilizzati con la versione più recente dell'Internet Protocol, e aprire un singolo record per visualizzare maggiori dettagli. ISC afferma che il progetto più ampio ha lo scopo di aiutare gli operatori a vedere quali client possiedono lease, analizzare i problemi di allocazione, individuare i lease appartenenti a uno specifico client, esaminare la cronologia dei lease di un client, identificare i dispositivi che ricevono un lease per la prima volta e accelerare il rinnovo anticipato o la rimozione in circostanze specifiche. Non tutti questi obiettivi vengono descritti come funzionalità completate in questa release. ISC sta cercando ulteriori casi d'uso per orientare le future funzionalità diagnostiche, in particolare per le reti con molte subnet e un gran numero di lease.
La seconda modifica principale è OpenID Connect (OIDC), uno standard che consente a un servizio di affidarsi a un identity provider esterno per confermare l'identità di un utente. In precedenza Stork supportava le credenziali archiviate nel proprio database e LDAP, un sistema comunemente utilizzato per gestire gli account utente di un'organizzazione. Quando OIDC è configurato, il server Stork opera come relying party e affida l'autenticazione a un provider esterno. Ciò consente di collegare l'applicazione al Single Sign-On (SSO), in cui un unico account organizzativo viene utilizzato per più servizi, e permette al provider esterno di richiedere la multi-factor authentication.
Per gli operatori DNS, Stork 2.6 introduce il monitoraggio centralizzato dei zone transfer di BIND 9. Un zone transfer copia tra server DNS i record DNS autoritativi, ossia i record che forniscono le risposte ufficiali per un dominio. Per diagnosticare un trasferimento bloccato o interrotto, gli operatori dovevano tradizionalmente esaminare i log di BIND e riunire informazioni provenienti da più fonti.
Gli agent Stork possono ora recuperare da più istanze BIND 9 i record dei trasferimenti avviati, completati e non riusciti. Il server mette in correlazione questi eventi e presenta un unico elenco per l'ambiente monitorato. Ogni record dispone di un timestamp con precisione al millisecondo e può mostrare l'ora di inizio, la durata, il server mittente e il server ricevente. Per i trasferimenti non riusciti, Stork può mostrare ulteriori dettagli ricavati dai relativi messaggi di log. Ciò offre agli operatori un modo diretto per distinguere le sincronizzazioni riuscite dai trasferimenti che non sono stati completati.
La release rende inoltre Stork compatibile con il Kea Configuration Backend, che archivia quasi tutta la configurazione di Kea in uno o più database. I suoi potenziali vantaggi includono il riutilizzo di sezioni di configurazione identiche su più server, il mantenimento di un'unica source of truth, l'applicazione delle modifiche tramite un'API con controlli logici in real time, l'integrazione di strumenti di terze parti o automazioni interne e l'uso delle proprietà del database per concorrenza, coerenza e modifiche atomiche. Il database può anche supportare reporting e replica per la fault tolerance in real time.
ISC segnala anche alcuni compromessi. L'adozione del backend può richiedere una preparazione significativa per l'integrazione o l'automazione; gli scenari supportati richiedono che la maggior parte delle operazioni di configurazione venga eseguita tramite l'API, che è disponibile soltanto per i clienti ISC con un contratto di supporto a pagamento. Nelle versioni precedenti non era possibile utilizzare Stork per gestire le configurazioni archiviate in questo backend.
Stork 2.6 può creare, modificare ed eliminare le subnet archiviate nel backend quando sono caricate le hook library `cb_cmds` e `subnet_cmds`. Una subnet è una porzione definita di una rete IP, mentre una hook library estende Kea con comandi o comportamenti aggiuntivi. I daemon che utilizzano lo stesso backend database e lo stesso server tag vengono raggruppati nel modulo della subnet, in modo che un amministratore non possa configurarli singolarmente in modi incoerenti. Gli amministratori possono scegliere i server tag associati a una subnet, determinando così quali server la ricevono. Il testo della guida distingue le operazioni che modificano il file di configurazione JSON da quelle che modificano il backend database.
ISC ha sostituito PrimeNG, la libreria di componenti dell'interfaccia utilizzata in precedenza per tabelle, paginazione, pulsanti e altri controlli. Alla fine di giugno, PrimeTek ha annunciato che avrebbe interrotto lo sviluppo della libreria open source PrimeNG per passare a un modello commerciale. ISC ha valutato la possibilità di mantenere autonomamente alcuni componenti, passare ad Angular Material e ricostruire l'interfaccia con HTMX. Alla fine ha adottato Optimus-UI, un community fork open source mantenuto tramite OpenNG, e afferma di aver previsto un contributo finanziario annuale a tale organizzazione.
Per quanto riguarda la manutenzione della sicurezza, il team di Stork sta sperimentando aggiornamenti settimanali delle dipendenze in risposta al numero di vulnerabilità segnalate nel suo ecosistema software. ISC afferma che la versione 2.6.0 contiene anche altri miglioramenti e correzioni di sicurezza documentati nelle note di rilascio. Poiché rimangono due problemi noti, gli amministratori dovrebbero leggere sia le note di rilascio sia la Stork Known Issues List, testare l'upgrade con la propria configurazione e conservare un percorso di ripristino prima di utilizzarlo in produzione.
Il source code è disponibile nell'area download di ISC. ISC distribuisce inoltre pacchetti per sistemi basati su Debian, Alpine e RPM tramite il proprio repository Cloudsmith; sono disponibili anche la Quickstart Guide e l'Administrator Reference Manual con indicazioni per il deployment. Il supporto professionale per Stork viene offerto come opzione di un contratto di supporto Kea DHCP. ISC propone il livello Bronze con supporto via email durante l'orario lavorativo, Silver con supporto via email e telefono 24 ore su 24 in base a service-level agreement e Gold con tempi di risposta più rapidi. Silver e Gold includono il Role-Based Access Control hook, mentre il costo dell'abbonamento dipende dalle dimensioni del deployment, misurate in base ai lease simultanei.
Per le organizzazioni che necessitano di assistenza esterna nella gestione di sistemi come questi, AEU-I offre servizi IT, infrastrutture e consulenza con un approccio security-first.
Termini spiegati
- DHCP
- Il Dynamic Host Configuration Protocol assegna automaticamente le impostazioni di rete e gli indirizzi IP ai dispositivi connessi.
- DNS
- Il Domain Name System collega i nomi di dominio leggibili dalle persone agli indirizzi di rete utilizzati dai computer.
- lease
- Un lease è l'assegnazione temporanea di un indirizzo IP a un dispositivo su una rete.
- OpenID Connect
- OpenID Connect consente a un'applicazione di utilizzare un provider esterno di account per verificare l'identità di un utente.
- Single Sign-On
- Il Single Sign-On consente di utilizzare un unico account organizzativo per accedere a più servizi.
- zone transfer
- Un zone transfer copia i record DNS ufficiali di un dominio da un server DNS autoritativo a un altro.
- Kea Configuration Backend
- Il Kea Configuration Backend archivia la configurazione del server DHCP in uno o più database anziché affidarsi soltanto a file locali.
- subnet
- Una subnet è una sezione più piccola e definita di una rete IP.
Come proteggerti
- Leggi l'elenco dei problemi noti e le note di rilascio di Stork 2.6.0 prima di installare l'aggiornamento su una rete di produzione.
- Prova prima l'upgrade su un sistema non di produzione, quindi verifica che le ricerche dei lease e i record dei zone transfer DNS vengano visualizzati correttamente.
- Crea una copia ripristinabile della configurazione attuale di Stork e Kea prima di modificare l'installazione.
- Se la tua organizzazione utilizza OpenID Connect, chiedi all'amministratore di richiedere la multi-factor authentication tramite il provider di accesso esterno.
- Verifica che le estensioni necessarie cb_cmds e subnet_cmds siano caricate prima di provare a modificare le subnet archiviate nel Kea Configuration Backend.
- Limita l'accesso alla dashboard di Stork al personale che ha realmente bisogno di visualizzare o modificare le assegnazioni di rete.
